PIAICKIE|T| | 
SITAITUS) | | 


DU>ra 


RIE|GI|S/TIE/R 


Tucson Amateur Packet Radio Corporation 


A Non-Profit Research and Develo) nt Corporation 
Fall 1994 President's Corner 
Issue # 56 Has much changed since 1985? 
We are about to find ourselves in the 10th anniversary of the TNC-2 
Published by: introduction next year, Amazing that it has only been ten years since the 


Tucson Amateur Packet Radio 
8987-309 E. Tanque Verde Rd.#337 
Tucson, AZ 85749-9399 
Phone: 817-383-0000 
FAX: 817-566-2544 


Office Hours: 
Tuesday - Friday 
9:00-11:00am, 3:00-5:00pm C.S.T. 
14:00-16:00, 20:00-22:00 UTC 


In This Issue... 
DCD Mod. in the MFJ 1270C TNC .....0...+. 3 
Kooling off the AEA PK-96.........ssss:1se2ss00 3 
AX.25 VOrSiON 2.2... ...escecscssssessssssseeiesseeess 3 
FCC 800-NUMDED esseessssseesnessesssessscesseennees 5 
13th ARRL DOC Report.....ssoesseccreerseeseees 6 
The ARAL National DCC as | sawit... ...... 9 
Impact of Part 97 Changes on 

HF Digital MOOS .....:...ccsscseecesesssanrene 10 
St. Louis Packet Network Update .......... 11 


Proposed Recommendation for 
Hierarchical Addressing Protocol.......14 


@USB8BS: Addressing Messages......... 
A High Speed Multicast-capable 
PaCKet SYSTEM ......sceccessesesesecsessssesse 20 
Help TAPR Create a Data Base of 
Regional Packet Organizations ...4..4.. 21 
TAPR Organization News: 
Nominations SOUGHL wascscissccsccsssecen2e 
Office / Phone Updates ........sses0 22 
Project and Kit Updates................00 23 
File Server UPCal........sseesseecsseeseeeene 24 


Proceedings Reprint ........sseseeeeseeen 
PartS ProCUreMeNt..........2ssecsessesseapers 


prepeenesenane 


Fall 1994 - Issue #56 


TNC-2, but have we come all that far? In 1985, packet was just gaining 
its stride to becoming the fastest growing Amateur mode ever. 
Digipeating was the main mode of semi-networking and BBSs were 
pretty much the main local resource. Talk of 9600 baud operation and 
debates on various networking strategies had already begun and were 
continuing, 


I think we can agree that Packet Radio consists of two main technical 
elements: Radios (RF) and Computers (Digital). I'll ignore the time, 
money, and manpower part of the equation in this discussion, but they do 
play a key part of what happens. Since 1985, the increase in Digital 
Technology has mirrored the consumer explosion. We were once paying 
$1500 for XT computers and now we get something a gazillion times 
faster for almost half the price. The problem has been that the RF side 
has not moved as fast. Various packet radio resources can be attributed 
to the increase in computer power. Look at the numerous, almost too 
many, BBSs, DX Clusters, Network Nodes, and all the others local 
resources. However, our success with computing power is still weighed 
down by our lack of RF capability. 


Those that have been able to go faster than 1200 baud, have been the 
few that understood how the radios and modems worked individually and 
together. In addition, they have had the necessary expertise and 
equipmient to make them work correctly. Many times I have read articles 
on why we need to work on Layer | (the physical, or RF layer) issues, 
but the critical mass of people required in a local area with the necessary 
expertise is hard to find, and even harder to get working together on a 
common project. The successful networks and digital groups have been 
those that have been successful with pulling this critical cross-section 
together to work on radio technology. 


Ten years from the introduction of the TNC-2, we find ourselves doing 
much the same thing, but only a lot more of it. Typically, a digital 
operator is on VHF/UHF operating with an older voice radio with a TNC 
operating at 1200 baud. This probably represents more than 90% of the 
digital community. HF communications has not been stuck in the same 
rut that VHF/UHF operations has. A lot has been done in modem and 
software development to improve the performance of HF digital 
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communications. Some of this can 
be contributed to the fact that many 
HF digital operators are willing to 
pay more for the increased 
performance, but this is not the 
entire reason. To get an idea on the 
type of increase in performance of 
HF digital operations, just read 
some of the papers in this year’s 
ARRL Digital Communications 
Conference, 


So, what is going to happen in 
our future if we cannot get things 
working better than they are now, 
while continuing to watch the 
number of digital operators 
increase. If we continue to operate 
as we have been, then we will 
probably be at deadlock 
eventually, if not already in many 
metropolitan areas. This 
impending overcrowding of the 
digital channels we use has caused 
some of the current availability of 
equipment. Several possible 
answers are now beginning to 
appear with the introduction of 
various manufacturer's radios that 


allow faster than 1200 baud 
operations. Although early reports 
seem to indicate that much still 
needs to be done on some of these 
radios to make them work 
correctly, they are a beginning to 
providing wider equipment 
selection. However, many of the 
Amateur radios available don’t 
work well in environments where 
many local resources are found to 
be residing (i.e. buildings with lots 
of RF floating about). The other 
limiting factor with these radios are 
cost. It is hard to justify one of 
these data-ready radios at the 
current price. For the price, you 
can go much faster; plus most of us 
don’t need all the bells and whistles 
present for just a data radio (which 
is a normal voice radio with 
additional functionality). The 
problem with going faster for the 
dollar with non-off-the-shelf 
equipment is again the need in 
having local expertise that can do 
it. 
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Cost and flexibility is the key to 
the radio problem, The unknown 
factor in the future is the current 
emphasis in radio technology now 
occurring with regards to PCS 
(Personal Communications 
Devices) and other wireless 
technologies. Much, much, much 
money is being spent on wireless 
communication'technology. Just 
look at the amount of money 
dropped on less than a Megahertz 
of spectrum this summer: 
$600,000,000, Amateur radio at 
some point has to be able to take 
advantage of this technology for 
what we want to do — that of 
having a low-cost, flexible, 
data-only radio. Amateurs have 
not been successful in inventing 
radio technology, but we have been 
successful, in the past, of taking 
existing technology § and 
transferring it to our needs. 


The other solution to better 
channel performance, is making 
modems that work on our current 
voice radios. I have heard many 
say, “I have a 14.4Kbps modem; 
why can’t we i do this over 
radios.” Whole papers can be 
written on why this has problems. 
Basically, telephone and radios are 
enough different to cause several 
problems with this concept. Most 
folks don’t understand that to have 
14.4Kbps work over the phone 
requires a rather complex 
modulation scheme _ that 
establishes multiple bits per baud. 
This works well in the known and 
stable telephone system, but the 
radio environment presents many 
factors which do not allow these 
current standards to work very 
well. However, the cost of DSP 
technology is going to continue to 
drop and at some point someone 
will introduce a less than $200 
modem that allows approximately 
2400baud at N-bit per baud to 
allow something around 9600bps 
over our current voice radios. 
Another answer to the task at hand. 
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The problem with any new work 
or project is finding folks capable 
of transferring the technology into 
the Amateur market. Who can 
predict the future, but we have to 
begin serious work on getting 
operating speeds above 1200 baud 
to take advantage of the many 
things that Amateurs want to do. 
As someone pointed out to me the 
other day, folks don’t want to 
spend money to go faster until 
there is some reason. For many, 
1200 baud still does what they 
want, 1200 baud AX,25 
operations will not go away for a 
long time. This is based on the 
number of TNCs that have been 
sold and are stil] operational. For 
many more, the lack of faster 
speeds in easy-to-use form has 
definitely slowed packet growth 
and is, I believe, one reason for the 
turnover in packet ’movers and 
shakers’ in the last five years. 


Development will continue in 
this area, but what form will it 
eventually take? Who can tell? 
We will all just have to wait and 
see. Someone will develop 
something that will transform what 
we are doing now. There are too 
many Amateurs ready to purchase 
something at the right price for 
someone or some manufacturer not 
to do something eventually. It is 
just a matter of time. 


— Greg Jones, WDSIVD 


TAPR DCD Mod. in the 
MFJ 1270C TNC 


TAPR member, Bruce Spacer, 
WB8VCM, reported that the 
TAPR XR2211 DCD modification 
might not be compatible with the 
new MFJ 1270C TNC. Bruce was 
kind enough to send his TNC to 
Lyle Johnson, WA7GXD, for Lyle 
to look into the situation. Lyle 
reports that the 1270C has the same 
2211 modem system that is used in 
the MFJ1278, so the XR2211 DCD 
mod. isn’t sufficiently useful to 
warrant its installation. 
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Kooling off the AEA PK-96 


Mel Whitten, KOPFX 
whitten @chestcp.atimail.com 


The new PK-96 ventless case 
gives one the impression that this 
little jewel is not related to its 
toaster cousin PK-88. Yes, it does 
run “kooler,” however as can be 
seen from the PK-96 power 
requirements, 400 ma has to be 
dissipated somewhere. And, that 
somewhere is in its NMOS 8530 
(Zilog’s SCC, a 40pin DIP) and 
7805 (TO220) regulator. I 
measured the 8530 case 
temperature at 55° C, and the 7805 
at 75° C. These are well within 
limits, but they contribute to nearly 
all the heat generated by the 
PK-96. All other [Cs are low 
power CMOS. 


If heat is a concern. especially if 
you “stack” your gear, then you 
may want (o consider replacing the 
8530 with a CMOS version also 
made by Zilog. The part number is 
Z85C300PSC and is available 
from many distributors (Newark 
Electronics has them). Like air 
conditioning, koolness doesn’t 
come cheap. The part costs 
approximately $15.00 in single 
quantities (a Newark price) but 
may be found for less from other 
sources. In contrast, the NMOS 
part is less than one third the cost. 


Unfortunately, this little mod. is 
not for the faint-of-heart. The 
8530 is a 40 pin through-hole 
device and not in an IC socket. 
However, I recommend using an 
IC socket for the CMOS 
replacement. If you do not have 
experience and the proper 
desoldering equipment, do not 
attempt to remove the 8530, 


Power consumption with the 
85C30 is around 100ma, 
depending on how many LEDs are 
on. The PK-96 now runs cool as a 
cucumber, If you run your gear 24 
hrs-a-day and your ambient shack 
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temperature may rise, (loss of your 
air conditioning!) then this mod. 
will help avoid a heat related 
failure. 

By the way, the “reset” switch 
on the rear of the PK-96 is a nice 
addition. Pushing it with 
power-on, however does not reset 
or “cold-start” the processor. To 
reset, power-down the unit, hold 
the button in, power it back up and 
release the button. All LEDs, 
except XMT will remain on until 
the PK-96 autobaud routine is 
performed. 'AEA did a nice job on 
the manual, however this 
information was apparently 
overlooked. 


AX.25 Version 2.2 


The ARRL Future Systems 
Committee met in Minneapolis at 
the Digital Communications 
Conference and among the various 
issues that were discussed was the 
LAPA protocol document. This is 
the extensive document that Bill 
Beech, NJ7P and Doug Nielsen, 
N7LEM, have been working on for 
the last two years. In summary, the 
committee recognized the huge 
amount of effort that had been put 
into this document by its authors 
and wished to extend its grateful 
admiration to them, This was no 
small task! To avoid confusion in 
the community, the committee has 
suggested that the title of the 
document should be AX.25 Level 
Two Version 2,2. The committee 
has requested some additional 
work be done before publication of 
a review document. The ARRL 
will undertake to duplicate and 
send copies to the known 
implementers for comment and 
feedback, The comment period 
will close sometime in March 
1995, After the review period, the 
comments will be evaluated, The 
document will then be edited as a 
result of the comments and 
submitted to the Future Systems 
Committee for approval. 
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TAPR 1995 Annual Meeting — March 3rd, 4th, & 5th, in St. Louis, Mo. 


Hosted by MoAmPS 
(Missouri Amateur Packet 
Society) 

Join some of the brightest and 
most enthusiastic of today’s packet 
developers/users, with a weekend 
full of Packet Radio and Digital 
Communications talks, 
presentations, SIG meetings, and 
two special Sunday Workshops. 
In addition, an advanced DSP 
symposium is planned for Friday 
for software developers of DSP 
systems. 


This year’s annual meeting will 
be the first held outside of Arizona 
and presents a unique opportunity 
for those unable to travel to Tucson 
lo attend meetings. 


The annual meeting informally 
begins Friday afternoon with the 
opening of the hospitality suite and 
continues later that evening with 
dinner. Dinner is always low-key 
and provides a great opportunity 
for those who arrive Friday to 
discuss and chat about projects 
before the rest of the weekend 
begins, Friday evening, after 
dinner, a mecting of the NETSIG 
will be held. The TAPR Board of 
Directors meeting will be held 
Friday morning. Those needing 
time at the board meeting, contact 
Greg Jones, WDSIVD. 


An advanced DSP symposium 
will be held Friday, March 3rd 
starting at 3pm or 4pm, through 
dinner (which will be provided), 
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and concluding sometime that 
evening. The purpose of the 
Friday symposium is to bring 
developers of DSP technology 
together to discuss future 
directions and technology. This is 
for those working with DSP 
technology currently, and not a 
session for introductory topics. If 
you would like more information 
on the symposium, contact TAPR. 


The annual meeting formally 
begins Saturday morning with 
presentations and papers, as well as 
discussion on other projects of 
interest throughout the day. Issues 
concerning packet networking and 
BBS operation are also anticipated. 
Lunch will be up to the participant, 
but facilities at the College will be 
available to cater individual tastes. 
Dinner will be held after the 
Saturday afternoon session and 
will include a prize drawing. After 
dinner, Special Interest Groups 
will meet and discuss issues, 


On Sunday, two workshops will 
be held. One will focus on Error 
Correction Techniques, by Phil 
Karn, KA9Q, while the second 
will focus on development of 
software/hardware for the 
TAPR/AMSAT DSP-93, by Bob 
Stricklin, NSBRG, and Frank 
Perkins, WBSIPM, 


These are exciting times for 
digital communications and 
TAPR. This year’s meeting 
should be a super-charging event 
for everyone who can attend! 


Call for Papers 

Papers are welcome from 
everyone. Although there is 
limited time during the weekend, 
all attempts will be made to allow 
those present to talk. Deadline for 
submission of papers is Monday, 
February 7th, 1995. Contact the 
TAPR office to request an author's 
information package. 
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Meeting Place and Hotel 

The TAPR Annual Meeting 
presentations, meetings, and 
workshops, will be held at the St. 
Louis Community College at 
Florissant Valley, Lodging and the 
hospitality suite will be at the 
Henry VIII Hotel and Conference 
Center, 4690 North Lindberg Blvd, 
St. Louis (Bridgeton), MO, 63044, 
Phone: 800-325-1588, 
800-392-1660 (in MO. only), 314 
731-3040, or FAX 314 731-4210. 
Rooms rates are $58 for single or 
double or $68 will get you a “suite” 
for single or double. The hotel has 
a coffee shop and nice restaurant, 
with another restaurant/bar next to 
it (in same parking lot). It is 
approximately 4 miles west of St. 
Louis Lambert Airport with shuttle 
service and approximately 10 
miles (all freeway) from the 
college. A block of 50 rooms will 
be held until February 4th, at which 
time those rooms will be released 
for general booking. If you are 
planning to stay at the hotel, it is 
highly recommended that you 
book your room prior to February 
4th, 1994. 
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FCC 800-Number 


FCC establishes 800 
number at Gettysburg 
licensing division as 
implementation of new 
customer service standards 
begins 

Declaring that “Customer 
service has taken on new meaning 
at the FCC,” Chairman Reed E. 
Hundt has submitted to the White 
House the FCC’s plan for new, 
improved customer service 
standards. 


Submission of the plan is in 
response to an Executive Order of 
the President which requires that, 


in order to carry out the principles 
of the National Performance 
Review, the Federal Government 
must be customer-driven and 
provide the public with “the 
highest quality of service delivered 
to customers by _ private 
organizations providing a 
comparable or analogous service.” 
Each agency is required to submit 
to the White House its individual 
plan for review. 


As part of its overall plan, the 
FCC initiated a pilot program 
using customers of the Private 
Land Mobile Radio Services. It 
held a series of focus groups with 
external customers and then asked 
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Registration 


Preregistration (before Feb 17th) 
Late Registration or at door 


$15.00 * 
$20,00 * 


$25.00 w/ Dinner** 
$30.00 w/ Dinner ** 


*Annual Meeting Registration includes: a copy of the TAPR 1995 
Proceedings and dinner Friday night (pizza out). Saturday lunch 
is not included in registration. Lunch will be up to the participant, 
but facilities at the College will be available to cater to individual 


tastes, 


**TAPR Dinner Saturday evening (limited space) includes a 
speaker (to be determined) and prize drawing! 


Late Registration or at door 


posium) 


Preregistration (before Feb 17th) 


Friday DSP Symposium 


$10.00 
$15.00 


Symposium attendees receive dinner (pizza during the sym- 


Sunday Half-day Workshops (8:30am - 12noon) 
#1 - Error Correction Techniques, Phil Karn, KA9Q 


Preregistration (before Feb 17th) 


Late Registration or at door 


Late Registration or at door 
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$10.00 
$15.00 


Workshop attendees receive a set workshop materials. 


#2 - Developing Software/Hardware for TAPR/AMSAT DSP-93, 
Bob Stricklin, NSBRG and Frank Perkins, WBS5IPM. 
Preregistration (before Feb 17th) 


$10.00 
$15.00 


Workshop attendees receive a set of workshop materials. 
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the employees of the Division to 
develop customer service 
standards, using the information 
from the focus groups. The 
Division then developed a 
brochure on customer service 
standards, including increased 
emphasis on response to telephone 
inquiries, It also identified the need 
for an 800 number for calling the 
licensing diyision. 

Effective immediately, all 
public inquiries to the FCC’s 
Gettysburg, PA, Licensing 
Division, Customer Assistance 
Branch, can be placed by calling 
800-322-1117. Hours of operation 
are weekdays from 8 AM to 4:30 
PM, eastern time. On the 
Commission’s 24-hour automated 
information system, callers dealing 
with interference complaints, form 
requests, availability of records, 
Amateur radio call sign 
assignments, Marine radio 
licensing information, fee 
information and processing times 
may access recorded information. 


Within the next 18 months, 
customer service standards will be 
developed for other areas of 
Commission operations to ensure 
that FCC customers receive the 
highest quality of service possible. 
As these new standards become 
available, the FCC will inform its 
customers. 


For more information contact 
Kay Hillegas at (717) 337-1215 
ext. 103. 
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13th ARRL Digital 
Communications 
Conference 


Compiled by Greg Jones, WDSIVD 


The [3th ARRL Digital 
Communications Conference was 
held in Bloomington, Minn, on 
August 19-21, 1994, hosted by the 
TwinsLAN ARC. The conference 
was attended by approximately 
150 and was one of the best in the 
last few years. Amateurs from 
twenty states and seven nations 
were present. A change was made 
in the organization of the overall 
conference, which resulted in three 
strands running through the entire 
conference. This presented some 
problems due to the overlap of 
several topics, but was one of the 
few negatives comments that were 
heard during the weekend, This 
format did allow for the numerous 
special interests to have time 
during the conference to discuss 
issues. The conference seems to 
have moved more to specialization 
and away from generalization as 
was the presentation format in the 
early conferences. 


Due to the number of sessions, 
each of the moderators was asked 
to write up a short overview of 
what happened during their session 
or forum, The following 
information is a compilation of 
those writeups as well as a brief 
review of each of the technical 
paper sessions. 


Technical Papers 


Automatic Packet Reporting 
System 

The paper (7 pages) discusses 
APRS (Automatic Packet 
Reporting System) and details 
several applications for APRS. 


MacAPRS: Mac Automatic 
Packet Reporting System 

The paper (13 pages) discusses 
APRS and the Macintosh 


implementation of it. Contains 
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more detailed information on the 
system and has pictures of several 
items. 


Packet, GPRS,APRS, and the 
future 

The paper (2 pages) discusses 
GPS (Global Positioning System) 
and how GPS is used in packet 
radio. 


G-TOR: The Protocol 

The paper (31 pages) details 
G-TOR. Includes: overview, 
technical details, speed transition 
diagram, SDL Diagrams, Huffman 
Decoding Tree, and C program 
routines. 


GMON-a G-TOR Monitoring 
Program for PC computers 

The paper (6 pages) describes a 
method for monitoring G-TOR 
communications. 


A Theoretical Eyaluation of the 
G-TOR Protocol Hybrid ARQ 
Protocol 

The paper (6 pages) discusses 
the advantages of using a hybrid 
ARQ protocol through theoretical 
evaluation. 


A Preview of HF Packet Radio 
Modem Protocol Performance 

The paper (4 pages) discusses 
protocol performance testing that 
was conducted at NTIA/ITS. 
AX.25, AMTOR, PACTOR, 
SITOR, CLOVER II, and Baudot 
were tested in a simulator and the 
results shown in the paper. 


How Amateur Radio 
Operators can Emulate an HF 
ALE Radio 

The paper (3 pages) how 
Automatic Link Establishment 
(ALE) can be used and some of the 
future potential for emulating an 
ALE radio using only typical 
Amateur equipment, 


FSK Modem with Scalable 
Baud Rate 

The paper (7 pages) discusses 
the design of a scalable baud rate 


modem. Paper _ includes 
schematics. 
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Designing Rural Telecom Sys- 
tems for Develéping Countries 


Formation of the BBS SIG 

The paper (3 pages) describes 
the formation of the TAPR BBS 
Special Interest Group and future 
goals, 


Broadcast, UI, and Un-con- 
nected Protocols - The Future 
of Amateur Radio 

The paper (4 pages) overviews 
user applications and the relevance 
of connected protocols and 
suggests formats for unconnected 
systems. 


On Fractal Compress of Im- 
ages for Narrowband Channels 
and Storage 

The paper (5 pages) comments 
on several new classes of 
compression techniques based on 
fractals. 
Fast CLEP Algorithm and Im- 
plementation for Speech Com- 


pression 
The paper (13 pages) describes 
a fast algorithm and 


implementation of code excited 
linear predictive (CLEP) speech 
coding for use over low-bit rate 
systems. An excellent technical 
paper. 
Wavelet Compression of Im- 
ages for Narrowband through 
Band Limited Channels 

The paper (10 pages) studies 
compression scheme using 
wavelets for image transmission 
through band limited channels. 


Papers that were not presented, 
but are in the proceedings include: A 
Proposal for a Standard Digital 
Radio Interface by Jeffrey Austen, 
K9JA. Computer Networks in 
Africa; From Utopian Discourse to 
Working Reality by Iain Cook. 
ROSE X.25 Packet Switch Status 
Update by Thomas Moulton, 
W2VY, A Primer on Reliability as 
Applied to Amateur Radio Packet 
Networks by Tom McDermott, 
NSEG. 
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Forums 


Developments in DSP for the 
Amateur 

The following topics were 
discussed: About five in the group 
had done or were considering 
doing some work with the TI DSK 
board. We discussed the use of this 
board and possible locations for 
obtaining the DSK which included 
TI distributors. TI has also 
introduced a new DSK which is 
based on the TMS320C50 and it is 
selling for about $100. Software to 
run on the DSK is available on 
Internet, ti.com. It was also noted 
that an Amateur has built a 
memory board to add to the DSK. 


There was a limited discussion 
about working with sound cards 
for the PC. The problem here 
seems to be availability of detailed 
information to change the function 
of these cards. The interfaces are 
not easily adaptable to Amateur 
radio for functions required to 
control your radio. The DSP-93 
being developed by TAPR was 
briefly reviewed. The DSP-93 has 
all the required hardware and 
software to Work in many Amateur 
applications. All of the information 
required to do additional software 
development is also being supplied 
with the unit. A detailed 
discussion of implementing filters 
with DSP systems ensued when 
Timewave presented information 
on the subject. Timewave has 
developed filters for the Amateur 
market using hardware they build. 
Filter design and implementation 
are key advantages to DSP. Also 
discussed was a recent article in 
QEX, the experimenters magazine 
from the ARRL, about Pactor, 
Code to implement Pactor and 
Amtor on a DSP based system was 
developed by HB9JNX and others. 
This code is available on internet at 
ftp.cs.buffalo.edu, Of those in 
attendance, over half of the group 
was actually active in development 
of Amateur related DSP projects. 
Of these about half were working 
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with TI based processors in the 
DSP-93 or DSK unit and most of 
the rest are working with the 
Analog Devices units. One man 
was working with Burr Brown 
products. 


The forum was a _ good 
opportunity to exchange ideas in 
an open, friendly environment. As 
the application of DSP products 
continues to grow in Amateur 
radio, I feel we will see more of 
these type of gatherings with more 
and more substance in each one. 


TCP/IP - What’s next? 

“TCP/IP is obsolete and dying” 
— The same statement had been 
heard over 12 years ago in the 
commercial world from the soothe 
sayers that saw OSI winning the 
protocol wars. Now look at it 
today. Broad-based commercial 
support in the popular network 
operating system (Netware, 
LANMan, etc.) and still going 


strong as the life blood of the 
Internet. No, TCP/IP is far from 
dead. It is emerging as the 


preferred way to interconnect 
computing platforms of different 
architectures and is the “on-ramp” 
to the Internet. 


The “Information Super 
Highway” (Infobahn) and its 
relation to the public Internet was 
discussed. It was thought that the 
two would be interconnected, but 
the Infobahn would operate more 
like the commercial business 
model, charging for services and 
access. 


There was a concern that the 
current DOS programming 
environment overly constrained 
the growth of NOS and thus 
TCP/IP use in the Amateur 
community. The Intel 64K 
segment architecture and DOS 
640K barrier proved to have 
serious limitations when adding 
new functions to NOS. Phil Karn, 
KA9Q, pointed out that you do not 
have to implement every new 
server application and Internet toy 
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that comes along in NOS! NOS on 
DOS is best deployed as a TCP/IP 
router and doing things specific to 
Amateur use like AX.25, 
NETROM, and BBS forwarding. 
Network alternatives such as a 
NOS front-end on ethernet or PPP 
to a Windows or Linux box should 
not be overlooked. 


It was pointed out that the next 
version of Windows (tm) would 
likely include TCP/IP as part of the 
operating system. This would go 
a long way toward providing a 
future common programming 
model (Winsock) for both 
Amateur and commercial use that 
can overcome the 640K batrier, 
The opportunity to adapt Amateur 
applications (BBS, Converse/Mail 
servers, gateways,...) while 
exploiting the Internet tools for 
Windows like MOSAIC, 
WS_FTP, Gopher, and Archie, is 
both a challenging and an exciting 
concept. Many of these tools are 
also available on other OS 
platforms (Linux, Unix, Mac, and 
OS-2), all interconnected with 
TCP/IP, ham radio digital 
networks, and the Internet. 


TCP/IP was seen by some as 
spectrum pollution and a channel 
hog. It was pointed out by Phil 
Karn, KA9Q, and others that this 
was not the case as NOS TCP/IP 
implements very sophisticated 
back-off algorithms and by default 
is probably the most polite channel 
user around, The multi-level 
protocol nature of TCP/IP provides 
tuning parameters at each level 
that can be set to maximize 
throughput while reducing channel 
congestion. Phil noted that many 
of the problems associated with 
TCP/IP are actually due to defects 
in link layer protocols (AX.25 and 
NETROM). 


TCP/IP-ready TNCs and digital 
radios were discussed. It was felt 
that the KISS mode operation of 
TNCs left a lot of room for 


improvement in terms of both ease 
! 
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of use and hardware support. 
Someone suggested that TNCs 
need to be more TCP/IP aware and 
implement most of the protocol 
stack with a_ terminal 
console/control interface to the 
host (ala Data Engine). Phil Karn, 
KA9Q, mentioned that it may be 
time to consider replacing the 
AX.25 link layer with more 
effective Forward Error Correcting 
(FEC) protocols such as those 
being developed by Qualcomm 
and others for cellular radio digital 
packet use. 


The need for a common 
messaging paradigm (addressing, 
store, routing, and format) for mail, 
news, bulletins, and forwarding 
was discussed. The richer 
programming and Internet-ready 
model provided by TCP/IP-based 
systems was seen as the tool that 
would lead the way toward 
consolidation of messaging 
systems in the future. The easier to 
use graphical development tools 
that are now available in powerful 
multitasking operating 
environments (Linux, Win 4.0, 
Unix, and OS-2) will enable a lot 
of previously untapped talents to 
be contributed toward developing 
applications that can be shared by 
all. 


ARRL Committee Updates: 
“Future Modes” 

Paul Rinaldo, W4RL, opened the 
forum explaining the environment 
we find ourselves in today with the 
FCC. He went to some detail to 
explain what the FCC 
reorganization was and how he 
thought it would affect us (lower 
priority, longer delays in 
processing changes, etc.) He 
stated that the FCC consensus was 
that their priority should be to 
identify new technology and 
techniques that would promote 
increased population of the UHF 
and Microwave Bands, Spread 
Spectrum was one of the areas 
mentioned. 
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Tod Olson, KOTO, presented the 
219MHz Committee’s general 
plan to the audience. The primary 
discussion was about those who 
want to use the band at baud rates 
less than 56KB, and concerns that 
the “Repeater Coordinators” in the 
Country aren’t really Spectrum 
Managers in many areas and may 
not be the best people to coordinate 
the digital activities. I spoke to 
both of these issues saying that the 
56KB requirement was good 
planning since frequencies 
occupied by lower speed 
operations are very difficult to 
displace (it is a guideline not a 
regulation), and that everyone 
should write to their ARRL 
Director about their spectrum 
management vs. coordination 
concerns since the Board is 
actively investigating this issue. 


Digital Data (Voice and Image) 
Transmission Method Develop- 
ments 

The presentation was started by 
talking about the Internet Multicast 
Backbone (mbone) and the audio 
and video conferencing tools that 
use it (vat, nv, wb), These tools use 
compression techniques at rates 
that, although fairly high, are not 
beyond reach of Amateurs; 13-64 
kb/s for voice and 128 kb/s 
(average) for medium-scan video 
(several frames per second). 
Software that implements them 
runs on standard workstations and 
is readily available over the net. So 
wouldn’t we like to see something 
like this come to Amateur radio? 
One place this could be done is the 
new 219-220 MHz band. Its 
“virgin” nature and the need to 
control transmitters make it an 
ideal choice for a high speed 
Amateur multicasting service that 
could carry, among other things, 
selected multicasts from the 
Internet MBONE (e.g., NASA 
Select during shuttle missions). 
Lots of discussions ensued about 
various coding schemes for both 
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voice and video, and a lively time 
was had by all. 


High-Speed (above 1200 baud) 
data transfer Methods and net- 
working techniques 

The High-Speed Data Transfer 
forum at the DCC started with a 
discussion of some of the new 
hardware — both RF and digital — 
that's becoming available for 
high(er) speed packet radio. The 
group was then treated to an 
impromptu presentation from 
Dewayne Hendricks, WA8DZP, 
on the current status of spread 
spectrum systems being used in 
Part 15 (unlicensed) service. Since 
these devices operate in or near our 
bands, they offer a lot of potential 
for megabit-plus, relatively short 
range links. After the break, the 
group resumed in an informal 
roundtable devoted to shoving fast 
data through slow radios. 


HF Data Transmission 
Methods - An overview of cur- 
rent modes and what’s coming 
next 

Technical discussions were 
about evenly split between modem 
design issues (DSP in particular) 
and protocol issues. Two general 
approaches to HF DSP modem 
design were discussed - matched 
filter and delay line discriminator, 
Noise reduction techniques were 
reviewed with special emphasis on 
DSP noise reduction delay. LMS 
adaptive noise reduction 
techniques appeared more suitable 
for use with HF modems than FFT 
bin clipping because of the lower 
process delay. Protocol 
discussions included AMTOR, 
PACTOR, G-TOR and a light 
discussion of PACTOR 2. Also 
some discussion on 300 bps 
packet. A survey of forum 
attendees showed _ broad 
capabilities and interests in 
running everything from RTTY 
through G-TOR and on to 300 bps 
packet. ’ 
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TAPR SIG Meetings (NET- 
SIG/BBSSIG) 

The NetSIG forum at the ARRL 
Computer Networking Conference 
in Minneapolis focused on how to 
gather and _ disseminate 
information about networking 
people and activities. We agreed 
that a database of both networks, 
and network builders, would be a 
good idea, It was agreed that we 
should start first by contacting area 
packet coordinators (where they 
exist) as an information resource, 
and build from there. There was 
discussion — but no real 
consensus — on how much, and 
what type, of data we should be 
looking for. The general feeling 
was that we should try to include 
information about individual 
networks but not (at least for now) 
individual nodes. The data should 
include contact information so that 
the primary builders/maintainers 
of each network segment are 
known. The hope is that a national 
network map can emerge from this 
effort, as well as a national 
database of network builders. 


Volunteers are currently 
designing the database format and 
we hope to start gathering 
information in the next few weeks. 
In the meantime, we'd be happy to 
get names and e-mail addresses of 
network builders, so we can 
contact them directly when the 
info. requests are ready. You can 
send that information to 
jra@ag9v.ampr.org if you'd like. 


The forum also had a lively 
discussion about why we're 
building networks, and what we 
want to do with them. As usual, no 
definitive answers emerged, but 
lots of folks had a chance to think 
about what draws us to this task. 


A Low Cost DSP Modem for 
HF Digital Experimentation 
This presentation touched on 
several reasons why HF digital 
offers unique opportunities for 
technical innovation and offered a 
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low cost DSP-based solution, The 
presentation included a number of 
interesting topics such as: HF 
propagation, its variability and 
how these factors set the stage for 
special considerations in modem 
design, i.e. good dynamic range 
and carefully designed filters. The 
presentation included a discussion 
of methods to increase dynamic 
range, criteria for demodulation, 
and detection using matched 
filters. The design of the linear 
phase, finite impulse response 
(FIR) filters for a typical HF 
modem was shown, This 
presentation showed that cost is no 
longer a factor for doing advanced 
digital experimentation using DSP 
-ithas becomea matter of applying 
classical DSP theory, A number of 
interesting technical points were 
discussed afterwards amongst 
attendees that indicated the high 
level of enthusiasm that exists for 
DSP technology. Although the 
meeting was the last one after a 
long busy day, it was well-received 
and well attended. 


If You Couldn’t Make It 


1994 Conference Proceedings 
are available from the ARRL for 
$12. (203) 666-1541. Past 
Proceedings of the Digital 
Conference are available from 
TAPR. 


Video tapes of the paper 
presentations are available. The 
complete set is $60, There are 
three tapes, which can also be 
bought individually. For more 
information contact Paul Ramey, 
WGOG, 16266 Finland Ave, 
Rosemount, MN, 55068, 


The TwinsLAN folks did an 
outstanding job and have set a fine 
trend for future DCCs, 

Next year's Digital 
Communications Conference will 
be co-hosted by TAPR and TPRS 
(Texas Packet Radio Society) in 
Sept. 1995, in the Dallas/Ft. Worth 
area. 
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The ARRL National DCC 
as | saw it... 


Dave Wolf, WO5H) 


The two most prevalent topics 
that struck me at the DCC were HF 
digital and DSP. A minor thread 
that was reflected (and is a 
perpetual topic of discussion 
among ham digital enthusiasts) 
was “we’ve got this great 
technology at our disposal, let’s 
find something useful to do with 
it.” APRS is one of the applications 
for packet that addresses this. 


Some of the discussions at the 
Futures Committee and among 
several of the hams during the 
weekend should be talked up. The 
only areas in Amateur radio where 
you don’t find plug-and-play the 
order of the day are in digital 
communications and satellites 
(with healthy overlap between the 
two). If ham radio is to continue as 
an outlet for technological 
experimentation, the rules and 
regulations must encourage this. If 
we are not allowed opportunity to 
experiment (and occassionally 
screw up in the process!), the kind 
of work that engineers do in their 
‘off hours’ in their ham hobbies 
will evaporate completely. All of 
the marvelous talent working on 
hardware and software for 
Amateur use will be dedicated to 
commercial endeavors. If one 
attends hamfests and sidewalk 
sales, it is easy to come to the 
conclusion that ALL hams are 
appliance operators who crammed 
enough technical knowledge to 
pass their tests. While this might 
be true for many in the ranks, it 
isn’t true for everyone. We've 
always had our share of operators 
and tinkerers. As a group, we must 
encourage our representative 
organizations and our regulators to 
continue to allow great latitude in 
the rules for experimentation. 
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Impact of Part 97 
Changes on HF Digital 
Modes 


Johan Forrer, KC7WW 


How does the new proposed 
amendment to Part 97 
accommodate future 
developments in the digital modes 
for HF? 

The digital community has been 
asked for input on the proposed 
amendments to Part 97. These 
changes deal with automated and 
semi-automated operations. My 
views are that of both a user and an 
experimenter. 


There effectively are two basic 
types of digital modes of 
operation: keyboard-to-key board 
(one-to-one) operations including 
Aplink semi-automatic, and the 
AX.25 packet networking/BBS 
(many-to-one) groups. These two 
modes require totally different 
needs, 


Lets look at AX.25 packet first: 
in this instance there are several 
stations sharing a common 
“channel”. Even if the channel is 
not occupied, this does not mean 
that the channel is free for use by 
keyboard-to-keyboard or 
semi-automatic operation. Present 
and future protocols that manage 
the flow of traffic require this — it 
is also anticipated that a great deal 
of these operations would fall in 
the “automatic” category. The 
main challenge here is to deal with 
the nature of HF propagation 
especially skip conditions and the 
“hidden transmitter.” It makes 
sense to give these traffic nets a fair 
chance of success by allocation of 
sub-bands for this type of 
operation. I also wish to point out 
that the present state of these 
operations are in great need for 
technical innovations — 
increasing their efficiency, making 
them more robust and giving them 
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added throughput capability — 
more about this later. 


The other type of operation, i.e. 
keyboard-to-keyboard and Aplink 
traffic handling, all require 
synchronous links. They are 
unforgiving when it comes to 
sharing frequency. Besides issues 
of operating courtesy, the nature of 
HF propagation often adds to the 
confusion caused by interfering 
stations. How often have I not 
heard several stations calling CQ 
on nearly the same frequency, but 
realizing that | can hear several of 
them, but they often can’t hear 
each other. Add to this the 
confusion added by skip stations 
activating Aplink stations in 
semi-automatic mode and one can 
understand the degree of 
unhappiness expressed by those 
just wishing to have a peaceful 
keyboard-to-keyboard QSO. Will 
the proposed amendment to Part 97 
allowing semi-automatic 
operations in the “real-time” 
sub-band be effective here? [ have 
doubts. Skip conditions will still be 
there and so will the problems 
caused by poor operator 
judgement. Will a 500 Hz 
bandwidth limitation, as it stands 
in the proposal, have the desired 
effect? I am not convinced either. 


QRM on one’s operating 
frequency is just as undesired 
whether it is 100 Hz or 800 Hz 
wide, I suspect that the intention 
was to “channelize” Aplinks in 500 
Hz slots and thus limiting 
bandwidth of such semi-automatic 
operations. This way it is intended 
that others can “avoid” those 
frequencies. I am not sure that it is 
realized that most of the 
commercial equipment 
manufactured for the ham radio 
market as used by semi-automatic 
operations, even with the best of 
intentions, emits in excess of 500 
Hz bandwidth. To illustrate this 
point further. take a simple 
example — two stations, each 
using the same TNC-type transmit 
a “clean” 170 Hz shift, 100 baud 
FSK signal, one at a 1|OOW output 
level, the other at 1K W. Do they 
occupy the same bandwidth? What 
happens when there is a QSO in 
progress 500 Hz away where 
signals are marginal? In the given 
example, the I00W signal 
probably will be tolerable, 
however, the power in the 
sidelobes of the high power signal 
will probably wipe out the weak 
signals in the adjacent channel. 
Does this sound familiar? I hope 
that this example illustrates that 


Table 1. 
Baud BPS __'Shi B.W. _ Modulation scheme 
1 100 100 170 370  noncoherent binary FSK 
2. 100 100 200 400 
3. 200 200 200 ~~ 600 I 
4 300 300 200 800 
la. 100 100 N.A. 200 DPSK 
2a. - - 
3a, 200 200 NA. 400 #£DPSK 
4a. 300 300 NA. 600 =DPSK 
5 100 300 8 800 8-ary noncoherent FSK 
6. 100 400 85 455 = 4 parallel PSK tones 
7. 100 800 85 560 4 parallel QAM tones 
8. 100 700 85 710  7parallel PSK tones 
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output power plays just an 
important role. The 500 Hz 
proposal needs to specify whether 
that is measured at the -3dB or 
-60dB levels in order to be 
effective. 


That brings me to my main 
concern: what about the future? I 
would hope that there is agreement 
that with the development of DSP 
applications, we are about to see 
significant technological 
advances. Besides the affects that 
it will have on future radios, the 
digital modes will most certainly 
experience marvelous 
technological advances. This 
includes possibilities for more 
robust bandwidth-efficient 
modulation schemes, better 
modems and protocols for both 
real-time operations and high 
speed networking. 


How does the proposed 
amendments to Part 97 affect the 
future of these developments? For 
sake of argument, I have put 
together a few possibilities in 
Table 1. I do not guarantee that all 
is feasible or accurate — please use 
your own judgement. Cases 1-4 are 
what we presently have — existing 
equipment. Cases la-4a shows the 
spectral efficiency achievable by 
using PSK instead of FSK. Case 5 
is something along the lines of the 
ALE format, just for interest sake. 
In cases 6-11, my assumptions are 
as follows: maximum baudrate 
~100 baud, minimum separation 
~85 Hz, parallel tones along the 
lines of MIL-STD-188. The four 
tone system for cases 6 and 7 is 
along the lines of the CLOVER II 
system and could possibly be 
implemented on something like a 
DSP sound card or the TAPR 
DSP-93, however, I suspect that 
8-11 may require multiple DSP’s. 


I do wish to point out that we can 
achieve a lot with a 1000 Hz 
bandwidth channel, that is within 
the present Part 97 framework. I 
hope that it could be shown that 


Fall 1994 - Issue #56 


1200 bps, perhaps even 2400 bps 
would be possible under favorable 
conditions. This would be a 
wonderful achievement for 
Amateur radio. On the other hand, 
Ido wish to express grave concerns 
for excessive power usage on such 
extended bandwidth modes. This 
would be contrary to all the efforts 
to develop spectrally-efficient 
high-speed digital modes. This 
obviously need careful further 
planning. 


In Summary 

The separation of the one-to-one 
vs. the many-to-one types of 
operations, into different 
sub-bands makes a lot of sense. 


The 500 Hz recommendation 
should be phrased to include how 
that bandwidth is measured, i.e. 
-60dB levels may be workable. 
Perhaps bandwidth and output 
power should be the norm. This 
needs some further thought. 


I respectfully request that the 
300 baud / 1000Hz shift, as 
presently contained in Part 97, be 
retained for future explorations, 
even if that restricts this to the 
“automated” sub-bands. 


I also strongly suggest that the 
HF digital group get involved with 
the VHF movement to improve 
and overhaul the existing AX.25 
networking protocol. In this 
regard, HF has some special 
considerations. 


I appreciate your time and the 
opportunity to voice my opinions 
and for considering this plea. 
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St. Louis TCP/IP Packet 


Network Update 


John Wilson, NOTYZ 


Presently, in St. Louis, Missouri 
we are working on setting up a 
9600 Baud TCP/IP Gateway to the 
Internet. St. Louis packet users 
formerly entered the Internet via a 
private LAN connection that 
routed packets via California and 
then to Chicago, Illinois where 
they finally entered the Internet. 


Working with Washington 
University’s Amateur Radio Club, 
WOQEY, the Missouri Amateur 
Packet Society (MoAmPS), and 
local St. Louis and western Illinois 
radio clubs, we are providing an IP 
Gateway Network that will route 
packets to regional nodes. These 
regional nodes will be on another 
backbone frequency, (yet to be 
determined), along with the 
Gateway node which is centrally 
located at the WUARC site. To 
cover the greater St Louis area, the 
Gateway node will have links 
initially to two existing Gracilis 
PackeTens. Future plans call for a 
higher speed links and additional 
Gracilis switches. We hope to 
have the St. Louis Gateway up and 
running by the end of the year. 


Renew Your Membership! 

TAPR sends out renewal 
reminders quarterly, but to find 
out when your membership will 
expire, check your mailing 
label. Your membership is very 
important. 
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Special Interest Groups 


SIG Updates 


Greg Jones, WDSIVD 


The TAPR Special Interest 
Groups have been active, but still 
are in a critical mode. Lots of 
communications and other types of 
information flow have taken place. 
Many on both lists have 
commented on the lack of focus on 
either SIG mailing list. As of right 
now, both SIGs have been wildly 
more successful than I had hoped 
for. My goal for both groups was 
to provide open discussion, but I 
knew that few final agreements 
would be derived from diverse 
backgrounds and interests. What 
has happened is that more people 
have seen what others are thinking 
and doing. For either group to get 
meaningful things accomplished 
will depend on small sub-groups or 
individuals within the SIGs 
working in a common direction 
and participating in building 
something useful, This might be a 
recommendation, a booklet of 
information, or whatever, The 
idea for these projects will have to 
come from individuals within the 
SIGs. If you see something worth 
doing, then start on it and try to get 
some help and then get feedback 
from the SIG or SIG chair, Ido not 
expect either current SIG chairs to 
be able to have enough time to set 
direction for everyone, Their job 
is to help channel and organize the 
groups to positive outcomes and to 
help individuals/groups with 
project ideas as a method of 
feedback. 


The BBS-SIG and NET-SIG 
still each have one chair heading 
the forefronts, Each SIG needs 
additional assistant chairs to help 
organize projects and do things. 
The BBS-SIG is working on two 
recommendations, one printed in 
this issue of the PSR. In addition, 
a BBS Sysop/User guide to 
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operations is in the works, All three 
of these things have been started by 
individuals with a concept that 
only needed a little feedback and a 
lot of encouragement. 


Three new SIGs will be forming 
this year. An HF-SIG will be 
formed to provide a focus point on 
HF digital issues. A DSP-SIG will 
begin to concentrate on DSP 
software development and issues. 
It is estimated that much of the first 
activity will center on DSP-93 
software development. And 
finally, a DSP-93 SIG to help 
support DSP-93 builder and 
hardware issues. 


Introducing the TAPR 
HF-SIG 


Johan Forrer, KC7 WW 


Objectives for the HF-SIG 


The purpose of the HF-SIG is to 
serve as a forum for those involved 
in experimenting, and developing 
digital applications for HF. 


Background 


HF offers unique challenges and 
rewarding opportunities for 
Amateur radio - it allows for both 
short and long distance digital 
communications without the 
involvement of specialized 
terrestrial or space-based 
equipment such as repeaters, or 
satellite transponders. It allows for 
one-to-one (keyboard to keyboard) 
as well as many-to-one 
(networking), modes of operation. 
These are quite different in 
philosophy and functional needs. 


The Amateur bands have seen a 
dramatic increase in diversity in 
technology as well as increased 
activity in the use of digital modes, 
This is due mostly to the 
availability of TNCs and 
application of personal computers. 
Basic technology, however. has 
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not changed much since the 60s 
and ts in great need for innovation 
to meet future challenges. 


Development of future 
technology for HF digital requires 
experimentation with several 
topics on communications such as: 


|. Bandwidth-efficient modulation 
schemes, i.e. for increased 
robustness, speed, and 
useability. These include 
various forms of m-ary FSK, m- 
ary PSK, or QAM using single 
or multiple carriers. However, 
other technologies such as 
spread-spectrum communica- 
tions also need to be explored. 


tO 


. Application of coding theory for 

error detection and correction 
for increased reliability. This 
will require the use of block 
and/or convolutional codes. 


3. Protocols to suit new proposed 
modulation and coding 
schemes. Various forms of ARQ 
and FEC are possible. The pos- 
sibilities for half and full duplex 
modes need to be explored. 


In addition, development 
platforms for such experimental 
work will most certainly receive 
attention. 


4. Programmable DSP platforms. 
Hardware, and software for ap- 
plication development. 


5. Host-based software. Typically 
this include low-level I/O, 
CUA/SAA compliant user-inter- 
face development, but also a user- 
contributed software repository 
for commonly-used algorithms 
such as frame synchronization, 
channel equalization, scrambler 
polynomials, fast CRC calcula- 
lions, various error-detection/cor- 
rection algorithms such as Golay 
(24,12), Reed-Solomon, and trel- 
lis/Viterbi codes for example. 
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Special Interest Groups 


Getting involved 


We require talents representing 
a wide range of topics such as 
mathematics (coding theory, 
signals and transforms), software 
engineering (algorithm 
development, real-time OS, 
low-level I/O, host OS), electrical 
engineering (analog, digital and 
RF), digital signal processing 
(theoretical, hardware and 
software), etc. However, there 
also is a simialr need for technical 
writers, beta testers, and project 
management. 


It is unlikely that this type of 
experimental work will be using 
any existing TNC hardware. A 
general-purpose programmable 
DSP platform, such as the TAPR 
DSP-93, a DSP-based sound card, 
or equivalent would be required as 
well as a fairly fast 386/486 or 
equivalent host computer for 
high-level software development. 


Besides development efforts, 
there will be ongoing on-the-air 
testing to establish how well 
theoretical ideas are working in 
practice. It is envisaged that there 
would be rapid evolution of 
modulation and _ protocol 
development and thus the need for 
fully programmable hardware. 


This introductory note is 
probably incomplete, however, it 
presents some perspective and 
direction for the HFSIG. I would 
appreciate further suggestions and 
feedback. 


Subscribing 
To subscribe to this mailing list 
send a message to 


‘listserv @tapr.org’ with the 
following line in the body of the 
message: 

subscribe list full_name 


Example: 
subscribe hfsig Joe Amateur 
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Here We Go 


I thought it would be of interest 
to provide further outlines of some 
ideas and get the discussion and 
interaction started. Please be so 
kind and take a few moments to 
study the summary given below. 


1). HF Comms at the physical 
layer 

Regardless of whether you are to 
apply results to networking or 
real-time keyboard operations, I 
believe that our efforts should first 
address issues surrounding the 
physical layer. 


2). Choosing the modulation 
scheme 

Which modulation scheme 
would be appropriate. HF demands 
a robust modulation scheme to 
address: 


2.1 Flat fading 

2.2 Selective fading 

2.3 ISI due to multiplath 

2.4 Unique noise characteristics - 
probably peculiar to each band 
2.5 Bandwidth limitations 


Experience on Amateur projects 
has shown that 100 baud, i.e., 10 
ms signaling elements (bauds) may 
be taken as a rough upper bound. 
FSK has been the main modulation 
method — in its non-coherent 
form, it is easy to implement, easy 
to tune, and has proven to be 
reasonably robust, It would be 
possible to implement m-ary FSK 
to “stack” several bits to a baud and 
thus increase throughput, however, 
it can be shown that for the given 
throughput, it will use a lot of 
additional bandwidth. The best we 
probably can do with FSK would 
be to implement a form of m-MSK. 


As an alternative, I would, 
however, like to suggest the use of 
some form of phase shift keyed 
modulation. The justification is 
that bandwidth may be used 
conservatively by using n-parallel, 
complex-modulated carriers. The 
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parallelism provides’ both 
throughput, and when conditions 
are poor, redundancy fallback. It 
would be possible, I believe, to 
initially develop a single channel 
using readily available hardware. 
Extension to multiple channels 
would follow, however, may 
require further research work into 
optimal pulse shape. 


3) Evaluation of Modulation 

Itis good engineering practice to 
first test these ideas by simulation. 
This requires computer simulation 
and modeling, 


The second phase would be to 
test the computer model with some 
real data. For this purpose, we need 
an HF channel simulator. In its 
simplest form, this could be a 
number of “gold standard” 
recordings off the air and made 
available as .WAV files that could 
be played through a sound card or 
applied directly in a simulated 
environment, Such standards 
should also be used to test and 
compare incremental development 
efforts. 


4) On-the-air testing 

It is essential that throughout 
early development, experience be 
gained from actual on-the-air 
testing, We will require a simple 
protocol to experiment with. There 
are several options that we can use 
here. 


5) Protocol development 

This will follow as soon as the 
we have a working modulation 
scheme, This probably will include 
either block or convolutional 
coding, compression etc, 
However, it probably will require 
an extensive development cycle 
similar to the modulation scheme. 
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Recommendation for 
Hierarchical Addressing 
Protocol 


Dave Wolf, WO5H 

Greg Jones, WDS5IVD 
Roy Engehausen, AA4RE 
Hank Oredson, WORLI 


Date: August 30th, 1994 


Comment Period on Table 
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through January 31st, 1995 


Send Comments to: Dave Wolf, 
WOSH, TAPR BBS-SIG Chair 
Packet: 

wo5h @woSh.#dfw.tx,usa,noam 
Internet: dwolf @tcet.unt.edu 

Fax: (817) 295-6232 


Introduction 

The TAPR BBS Special Interest 
Group recommends the adoption 
of the x.3.4 hierarchical address 
protocol. 


After discussion of previous 
articles on hierarchical addressing 
standards [1, 2] and taking into 
account international issues of 
regional/state name sizes, the 
TAPR BBS Special Interest Group 
recommends the adoption of the 
x.3.4 standard on an international 
basis. ’x’ is defined as 2-, 3-, or 


ARG Argentina SLV 
AUS Australia FIN 
AUT Austria FRA 
BEL Belgium PYF 
BMU Bermuda DEU 
BOL Bolivia GRC 
BRA Brazil GRL 
BRN Brunei GTM 
BGR Bulgaria HTI 
CAN Canada HND 
CHL Chile HKG 
CHN China HUN 
COL Colombia ISL 
CRI Costa Rica IND 
CUB Cuba IDN 
DNK Denmark IRL 
DOM _ Dominican Republic ISR 
ECU Ecuador ITA 
EGY — Egypt JPN 
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4-letter region names as defined by 
the country. 


Examples of x.3.4: 
@WA6GVD.CA.USA.NOAM 
@EA2CMO.EAZ.ESP.EURO 
@FS5JGK.FAQIFRA.EURO 


Regional identifiers may be 
duplicated in different countries 
(i.e. AK, Alaska, USA, could be 
used in another country as a 
regional identifier); however, 
Country and Continental 
identifiers should not be used as 
regional names. 


It is important to note that there 
is a distinct and significant 
difference between hierarchical 
addresses and flood designators. 
Hierarchical address elements are 
common to all messages types 
(bulletins, private, and traffic) and 
are the foundation of the digital 
forwarding system. Flood 
designators are used for routing 
ands filtering —_— bulletins. 
Geographical flood designators are 
likely based upon hierarchical 
address elements. It is therefore 
important that any allempt to 
establish standards concentrate 
first on hierarchical address 
elements. Standards for flood 
designators can follow, 


It is the purpose of this 
document to generate a changing 
recommendation that reflects 


TABLE 2: Country Identifiers 


El Salvador PRK _ Korea, North 
Finland KOR Korea, South 
France LBN Lebanon 
French Polynesia LIE Liechtenstein 
Germany LUX Luxembourg 
Greece MYS Malaysia 
Greenland MEX Mexico 
Guatemala MCO ~—- Monaco 
Haiti MAR — Morocco 
Honduras NLD Netherlands 
Hong Kong NZL New Zealand 
Hungary NIC Nicaragua 
Iceland NOR — Norway 
India PAK Pakistan 
Indonesia PAN Panama 
Ireland PRY Paraguay 
Israel PER Peru 
Italy PHL Phillipines 
Japan POL Poland 
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Table 1: Continent 
Identifiers 


Europe 

Mediterranean 

Indian Ocean including 
the Indian subcontinent 
Middle East 
South-East Asia 

The Orient 

North America 

Central America 


Caribbean 
South America 


Australia/New Zealand 
Eastern Pacific 
Northern Pacific 
Southern Pacific 
Western Pacific 


Northern Africa 
Central Africa 
SAFR Souther Africa 


ANTR Antarctica 


current hierarchical routing. The 
Reference Tables will be changed 
as necessary to reflect current 
configurations within the 
international BBS network. These 
tables will need to be changed and 
updated in order to meet future 
needs of user and sysops. 


EURO 
MEDR 
INDI 


MDLE 
SEAS 
ASIA 


NOAM 
CEAM 


CARB 
SOAM 


AUNZ 
EPAC 
NPAC 
SPAC 
WPAG 


NAFR 
CAFR 


Hierarchical Routing Syntax 
Summary 

This summary uses a modified 
Backus-Naur form to summarize 
the syntax for hierarchical 
addressing. [] = optional 


! 


PRT Portugal 
ROM Romania 
SAU Saudi Arabia 
SGP Singapore 
ZAF South Africa 
ESP Spain 

SWE = Sweden 

CHE Switzerland 
SYR Syria 

TWN Taiwan 

THA Thailand 
TUR ‘Turkey 

GBR United Kingdom 
USA United States 
URY — Uruguay 
SUN USSR 7??? 
VEN Venezuela 
YUG —_ Yugoslavia 
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Table 3: Region Identifiers organized by Country Codes. 


{Countries not listed had FCAL ?? SWE ____ Sweden ND , 
no known region identifiers FPDL ?? AC 2? NE 
at the time of publication. FMLR ?? NH 
Please forwardany additional FNOR ?? : : NJ 
information during the com- FCOR ?? reunite STOR IRTRES NM 
ment period. FPOC 7? y NV 
ARGArgentina FAQL ?? USA United States NY 
BA 2? DEUGermany AK Alaska OH 
CF 2? BY 7 AL Alabama OK 
BEL Belgium a ia on 
HT 29 GTM ___ Guatemala AZ Arizona PA 
LG 40 none CA “sally RI 

3 co olorado SC 
A 8 ee 99 CT Connecticut SD 
i IFVG 9 DE Delaware TN 
RS 2? IPIE 29 GA Georgia UT 
sp (2? PUG 2? HI Hawaii VA 
CANCanada ISAR 2? “4 sd Aa 
NF Newfoundland ISIC 2? iL ilinois wi 
AB Alberta ITAA 2? IN indi 
BC _ British Columbia VEN 2 is % lana WV 
MB Manitoba MO 2? a. “pemen WY 
NB New Brunswick PRT Portugal LA irises 
NS Nova Scotia CTPT 7? MA —_ Massachusetts MVD 
NW Northwest Territories i MD Marviand 
ON Ontario ESP Spain ME HF ry on 
PQ Province du Quebec EACA ?? ane 
MI Michigan 
SK Saskatchewan EAH 2? Mil Mississippi 
YK Yukon EASE 7? Seite 
FEAHU 29 MN Minnesota 
FRA France EAZ 22 MO Missouri 
FCEN ?? MT Montana 
FRPA 2? NC North Carolina 


@hierarchical_address = 
bbs.[#octothorpe. ][region. ]count 
ry.continent 


bbs = valid callsign as defined 
by local communications authority 


#octothorpe. = 
#area.[#octothorpe. ] 


#area = The area as defined by 
the local region. See Table 4 for list 
of current area identifiers 


region = 2-, 3-, or 4-character 
region identifier as defined by the 
country. See Table 3 for list of 
region identifiers 

country = 3-character country 
identifier as defined by ANSI X.12 
and EDIFACT. Published in ISO 
3166-1981(E/F). See Table 2 for 
country identifiers 


continent = 4-character 
continental identifier. See Table | 
for continental identifiers. 
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Examples: 
F6CNB.#SETX.TX.USA.NOAM 
KB7WE. #WWA.WA.USA.NOAM 
OH6RBV.#VAA.FIN.EURO 
SK2AT.AC.SWE.EURO 
OH6RBG. FIN. EURO 
KE7KD. #NONEV.NV.USA.NOAM 
WX3K.#NOCAL.CA.USA.NOAM 

References: 


|. Jenkins, Lew (N6VV), Dave 
Toth (VE3GYQ), and Hank 
Oredson (WORLI). International 
Routing Designators. Proceedings 


of the ARRL 7th Computer 


Networking Conference. 
Columbia Maryland. October 1, 
1988. pp. 91-93. 


2. Clark, Tom (W3IWI). Some 
comments on the Hierarchical 
Continent Address Designator. 
Proceedings of the ARRL 9th 
Computer Networking 
Conference. London, Ontario 
Canada. September 22, 1990. pp. 
278-279. 
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North Dakota 
Nebraska 
New Hampshire 
New Jersey 
New Mexico 
Nevada 
New York 
Ohio 
Oklahoma 
Oregon 
Pennsylvania 
Rhode Island 
South Carolina 
South Dakota 
Tennessee 
Texas 
Utah 
Virginia 
Vermont 
Washington 
Wisconsin 
West Virginia 
Wyoming 


2? 


Table 4: Hierarchical 
Addressing Area 
Definitions 

This table to be defined 
during the comment period. 


All readers are asked to 
submit their regional area 
definitions for inclusion in the 


table. 


Be sure to include the 


region and country. For 
example:, #DFW.TX.USA 
Dallas/Ft Worth Texas Area 
would be an entry in this table. 


#EPA.PA.USA 
#WPA.PA.USA 
#DFW.TX,USA 


East PA 
Western PA 
Dallas/Ft.Worth, TX 
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RUDAK-U Update 


Lyle Johnson, WA7GXD, 
for the RUDAK-U team 


RUDAK-U is a digital 
communications system being 
designed for you! Currently slated 
to fly aboard the International 
Phase 3D Satellite (P3D) being 
built by AMSAT organizations 
worldwide, RUDAK-U will bring 
real-time digital communications 
with global coverage. 


Presently, your packet traffic ts 
typically handled on VHF/UHF 
channels at 1200 bps or 9600 bps 
data rates, The station you directly 
communicate with is usually less 
than 25 miles (40 km) away. Most 
of your traffic is in the form of 
electronic mail, bulletins and 
programs or data files. 


You've been conditioned to 
believe that packet is for 
non-real-time communications, 
and you’ve exploited this 
limitation. Some of you have tried 
to use packet for 
keyboard-to-keyboard QSOs and 
have had the local “experts” tell 
you are clogging up important file 
transfer channels, and that packet 
isn't intended for such 
communications. 


Existing packet satellites have 
been optimized to exploit their low 
earth orbits (LEO) and are, in 
effect, flying mailboxes. 


Well, a new dimension is about 
to be added to _ packet 
communications in particular, and 
Amateur digital communications 
in general. 


RUDAK - What? 

RUDAK-U will be able to see 
half the world at a time, and from 
almost any location on the planet 
you'll have access to almost all the 
rest of it over a 48-hour period. It 
will have the file 
store-and-forward ability you’re 
already accustomed to. We’re 
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hoping to augment the spacecraft’s 
memory systems with 
ground-based mass storage 
facilities. 


But let’s look at the real-time 
opportunities, 


RUDAK may have as many as 
ten (10) communications channels 
operational ata time. During these 
times, multiple QSOs can be 
carried out using multimedia, 
digital voice, and so forth. At other 
times, only a few channels will be 
operating. Some of these channels 
will likely be “scheduled” to 
minimize QRM (oops, I meant 
“collisions”). 


There is a possibility that there 
will be a special, 
bandwidth-efficient 256 
kilobit/sec modem aboard the 
satellite and that RUDAK-U will 
have the opportunity to connect to 
it. We’ re talking serious capability 
here, like real-time motion video! 


Speaking of video, RUDAK-U 
is expected to be the primary 
communications path for images 
from the SCOPE earth-imaging 
cameras on Phase 3 D, It will also 
be a source of precise information 
from the on-board Global 
Positioning Satellite (GPS) 
experiment, 


Some of the time, RUDAK-U 
will have only one or two 
downlinks running, but with 
sufficient power that a ground 
station with a low-noise front end 
and asmall beam antenna (perhaps 
5 or 6 elements, maybe fewer) will 
be able to fully utilize. At other 
times, when more downlinks are 
on or high-speed links are in use, a 
better antenna will be required. 


As you can see from this brief 
sketch, RUDAK will have 
something for everyone in the 
digital communications 
community, 


RUDAK has something for you! 
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RUDAK - When? 

The design has been worked out 
at the block level, and detailed 
circuit design is being completed 
as this is written. 


Engineering prototypes are 
expected to be built and shaken 
down in the December 1994 
timeframe. Flight hardware 
construction will begin in January 
and the flight module will be 
delivered to the satellite 
integration facility in Orlando, 
Florida, in March, 1995. 


RUDAK - Some Details 
RUDAK will carry 
independent computers. 


CPU-A will be based on the 
NEC V53 processor. This 
processor is a superset of the V40 
flying aboard the MicroSats and 
scheduled to fly on UNAMSAT. 
The V53 is flying now as part of 
AO-27. It will have 16 megabytes 
of error correcting memory, and 
sixteen (16) DMA-based 
communications ports. 


CPU-B will be based on the Intel 
i386EX processor, This is a 
high-end controller and is being 
investigated for use on future 
Amateur spacecraft as well. Like 
CPU-A, this one will have 16 
megabytes of memory, with error 
correction to help protect against 
the hazards of radiation upsets. It 
will have fewer communications 
channels than CPU-A due to 
limited DMA resources (8 
channels). 


two 


For comparison, the MicroSats 
have 256 kilobytes’ of 
error-correcting memory (1/64th 
the amount of either CPU on 
RUDAK-U) and a total of 8-1/4 
megabytes of memory (about 1/2 
the amount of either CPU on 
RUDAK). They have six (6) 
DMA ports. 


The CPUs will be tied together 
by a high-speed first-in first-out 
(FIFO) buffer. This will 
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effectively enable each CPU to 
have access to much of the other 
CPU’s memory resources. 


The modems for RUDAK will 
interface to the IF switching matrix 
on P3D. This means a different 
kind of interface (similar to that 
pioneered by RUDAK-II aboard 
RS-14/AQ-21) and the ability to 
operate on multiple frequency 
bands along with the analog 
transponders. 


One of the design goals of 
RUDAK-U is to be compatible 
with existing packet users. 
Another goal is to be flexible for 
future operations. Since we expect 
P3D to be operational for more 
than ten years, we don’t want 
people to have to use today’s 
(obsolete) technology. 


Each CPU will have a modem 
module. Each modem module will 
have the following lineup: 


(1) One 1200 bps Manchester 


uplink/PSK downlink for low 
speed, lower-power operation. 


(2) Two 9600 bps FSK 
uplink/downlink for “typical” 
operation. These modems will be 
switchable to 19.2 kbps and 
perhaps as fast as 38.4 kbps. 


(3) At least two DSP-based 
modems. These will allow 
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operation at reasonable data rates 
(we are looking at making them 
capable of 56 kbps operation) as 
well as more complex modulation 
schemes. They will of course be 
able to provide compatibility with 
today’s satellite standards. 


RUDAK - How 

RUDAK-U is happening 
because some volunteers are 
pouring countless hours of toil and 
love into it. These volunteers have 
reduced the dollars required to 
about $60,000, TAPR [1] has set 
up a special fund for supporting 
this project. Please consider 
making a donation. Consider it an 
investment in the future of 
Amateur digital communications 


[2]. 


Just so you don’t think your 
money might be spent on a 
Caribbean Cruise, here is a 
condensed breakdown of the 


budget: 

Module Flight___ Engineering 
CPU-A 590 330 
CPU-B 620 310 
MEMORYx2 5080 1340 
MODEMx2 =: 1760 1140 
TOTAL 14890 5600 


NOTE: A complete system 
includes one CPU-A, one CPU-B, 
two MEMORY and two MODEM, 
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There will be four engineering 
units and two flight units. 


Parts $52,180 
PCB charges 8,800 
Travel, Meetings, Initial Integration 5,500 
Parts Discounts (2,880) 
Estimated Total $63,600 


Like the rest of P3D, RUDAK-U 
is a truly international effort. The 
main players in the technical team 
include Lyle Johnson (Project 
Manager), Peter Guelzow, Chuck 
Green, Harold Price and Jeff Ward. 
We are all licensed Amateurs with 
long experience in volunteer 
service to Amateur radio, Amateur 
packet radio and Amateur 
Satellites. 


As you can tell, we’re very 
excited about this project. 


Won’t you help us make this 
dream a reality? 


[1] TAPR, 8987-309 E. Tanque 
Verde Road #337, Tucson AZ 


85749-9399. Phone: (817) 
383-0000. Fax: (817) 566-2544. 
MC/Visa Accepted. 


[2] If you are a U.S. taxpayer 
itemizing deductions, such 
donations may be tax-deductible. 
Consult your tax advisor. Your 
mileage may vary. 
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@USBBS: 
Addressing Packet 
Bulletins 


By Brian Battles, WS1O 


QST Features Editor 

ARRL HQ 

225 Main St 

Newington, CT 06111 

ws lo@wslo-2.ampr.org 
WS10 @ WIEDH.CT.USA 


Anyone who has visited the 
Never Land of written electronic 
communication knows that the 
open forum provided by telephone 
bulletin boards (BBSs), the 
Internet and other similar media 
have long offered users exciting, 
effective means of discussing, 
debating and announcing diverse 
opinions, issues and emotions. 
These environments have 
traditionally relied on two basic 
means of controlling the content of 
messages posted and behavior of 
those who choose to participate: 
(1) a “gatekeeper” and (2) peer 
pressure. The gatekeeper (SysOp) 
can decide who may post material, 
what may be posted and if it will be 
forwarded. Peer pressure provides 
a vocal, but officially impotent 
form of obligation to conformity, 
It does this through friendly 
advice, admonishment, 
chastisement, and outright insult. 
In Amateur packet radio, a third 
entity wields a measure of control: 
The FCC determines what is 
legally acceptable. 


Traditional networks, such as 
the seminal Fidonet, maintain an 
accepted level of decorum through 
a voluntary standard of 
cooperation and a hierarchy of 
people who have definite levels of 
enforcement authority. Specific 
areas, also known as “conferences” 
or “forums” (or Echoes, in the case 
of Fidonet), are designated where 
users may wrile messages 
pertaining to that area’s usually 
narrowly defined topic. A 
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volunteer, often selected by 
conference participants, acts as a 
moderator. This person’s job is to 
regularly post a set of conference 
rules and to monitor posted 
messages. Theoretically, the 
moderator’s presence is to serve as 
a referee, to inform users of 
transgressions and to reduce the 
amount of peer-to-peer bickering 
over each others’ perceived 
misbehavior. Users who 
repeatedly violate the rules after 
sufficient warnings from the 
moderator are reported to the 
SysOp of the site where the user 
logs in to post messages. It’s the 
SysOp’s responsibility to counsel, 
rehabilitate, educate, or bar the 
user’s access to the conference. 
The SysOp is motivated by the 
potential consequence of having 
his BBS excommunicated from the 
network if he fails to exercise the 
proper control over his users’ 
behavior, 


In the world of Amateur packet 
radio bulletin boards (PBBSs), 
however, there are differences that 
make control and adherence to 
standards difficult to implement. 
The spirit of democratic, 
uncensored participation that 
offers many advantages to radio 
Amateurs precludes most SysOps 
from refusing access to 
uncooperative users, induces them 
to make undesirable messages 
available to all of their local users, 
and even to forward such messages 
to other PBBSs in the network. 
SysOps have been roundly and 
publicly criticized for refusing to 
forward bulletins they deemed to 
be inappropriate, even if only for 
purely technical reasons. In raging 
discussions, misinformed or 
selfish users maintain that a SysOp 
is obligated to accept and forward 
their message without question, as 
long as it doesn’t expressly violate 
any FCC rules. (This is, by the 
way, entirely untrue. No SysOp is 
under any obligation to do 
anything whatsoever with any 
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radio Amateur’s messages and the 
FCC rules state that a PBBS is its 
SysOp’s privately operated radio 
station, for which the SysOp is 
permitted — in fact, expected — to 
monitor and control the material it 
transmits.) 


Educating Users 


To turn to a more basic, 
pragmatic issue, many packet 
operators have ‘spent many hours 
discussing the frustration of having 
these PBBSs, supposedly designed 
and built for the purpose of 
carrying person-to-person mail 
traffic and occasional bulletins of 
general interest, into electronic 
“classified ad pages.” Notices that 
carry announcements of items for 
sale, swap, or wanted, noticeably 
outnumber other single types of 
bulletins. Because of its 
convenience, low cost, and 
apparent effectiveness, PBBS 
users inundate the airwaves with a 
nationwide swapfest day and 
night. Most messages in this 
category are individually 
harmless, but when viewed as a 
class, are the greatest consumers of 
computer storage space, 
message-forwarding time and 
bandwidth, 


Many SysOps and PBBS users 
complain that all you ever see 
listed on a PBBS today are 
screenfuls of SALE@USBBS 
messages and so on. It’s an 
understandable lament: there’s a 
lot of stuff'in there, but most of it 
is “junk mail* most users never 
read, Forexample, aham in Boston 
isn't likely to care about a personal 
computer or hand-held transceiver 
being sold by an Amateur in 
Seattle. But there are hundreds, 
maybe thousands of Amateurs in 
Washington or perhaps the Pacific 
Northwest region who will read 
and respond to such a notice. So 
why waste the time and bandwidth 
to send this bulletin ping-ponging 

! 
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all over the US by addressing it so 
it’s forwarded to @USBBS? 


In a sadly ironic way, most 
packet traffic isn’t nearly as 
efficient as the non-SysOp packet 
operator believes. Notices of items 
too insignificant or unwieldy to be 
easily sold to Amateurs hundreds 
of miles away are routinely sent out 
addressed to SALE@USBBS. 
This is a lazy. or perhaps 
misunderstood, format that causes 
thousands of hams in a state like 
Alabama, for example, to have 
their local PBBSs spew forth 
several screens worth of listings for 
hand-held transceivers, parts, 
batteries and other such items 
being offered by hams in Oregon 
or Alaska, which are likely to be 
sold by the time they reach most 
out-of-state PBBSs, anyway. 


SysOps: Can You Do It? 


Perhaps there needs to be a 
system implemented by which 
SysOps would be asked to 
voluntarily help educate users, 
Each user could be compelled to 
read an educational message about 
the most appropriate way to 
address bulletins before he’d be 
given the privilege to post a 
message intended to be forwarded 
to other PBBSs. This would 
require at least two things: (1) The 
PBBS software would have to 
support a method of doing so, and 
(2) The SysOp would have to be 
willing to invest whatever 
additional time it might take to 
grant access to potential users who 
acknowledge that they’ ve read and 
understand the proper procedure. 


Is it reasonable to suggest that 
PBBS SysOps route incoming 
messages addressed to @USBBS 
to some kind of holding bin, unless 
they meet certain criteria (e.g., 
ARL, KEPS, AMSAT, FCC, 
SYSOP, DX, etc)? For example, 
do we really need so many SALE, 
WANTED, HELP, FEST and 
EXAM bulletins addressed to, and 
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circulated over the airwaves to, 
@USBBS? Does it offer any real 
advantage to the user who posts it? 
Isn’t it more efficient, timely and 
appropriate to post most bulletins 
to a local, state, or regional 
circulation? Could PBBS SysOps 
do this, and would they want to? 
How much extra time and effort 
would it take? Can any of this be 
automated? Will an investment in 
the time and energy now pay off 
later with Jess “junk mail” coming 
through each PBBS in the near 
future, if users can be taught to cut 
down the unnecessary @USBBS 
traffic? And how much actual 
improvement would that offer all 
Amateurs, regarding the possible 
decrease in traffic transmitted via 
VHF/UHF backbone and HF 
forwarding? 


This could certainly be 
implemented in a friendly manner, 
with errant users gently instructed 
in a friendly, helpful manner, Each 
PBBS SysOp could prepare a 
“boilerplate” text he could use to 
inform a user whose postings were 
held or rerouted that would explain 
what was done, why it was done 
and how to avoid such faux pas in 
the future. A standard one-page 
(one screen?) message from the 
SysOp could simply inform the 
user that @USBBS is, by 
conventional agreement, reserved 
for messages that, by their inherent 
nature, lend themselves most 
advantageously to distribution to 
the entire nation’s Amateurs. It 
could advise the user that buying, 
selling, swapping or evaluating 
almost any Amateur Radio item 
could be quite effectively 
accomplished via a local or 
regional bulletin, and that he 
should seriously consider if the 
hams in a distant state will care or 
be able to take advantage of the 
information in certain types of 
messages. 
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The Alternative 


This primarily concerns 
standard AX.25 PBBS users and 
SysOps because more advanced 
software, such as that used for 
TCP/IP networking, doesn’t even 
involve PBBSs as most hams have 
come to know them. A TCP/IP user 
finds his incoming mail neatly 
stored in his own private mail area 
on his own computer’s disk drive. 
Bulletins can be forwarded only to 
TCP/IP operators who specifically 
request them, by category, from 
individuals or from stations that act 
as “galeways” to collect useful 
messages from local AX.25 
PBBSs and mail them directly only 
to those who want to see them. 
Ideally, if all U.S. packet stations 
operated TCP/IP software, rather 
than just plain, “built-in” AX.25 
TNC firmware, the traditional 
PBBS could be eliminated and 
Amateur packet radio would 
function more like the Internet. 
Each station would be accessible 
directly by every other station, and 
each Amateur could choose to 
“subscribe” to “newsgroups” that 
encompass particular topics. 


Let's hear what you think, as a 
packet operator, and especially as 
a PBBS SysOp. Poke holes in these 
suggestions or offer ideas on how 
to improve them. Be constructive 
and thoughtful, and perhaps we’ll 
be able to slowly educate our 
fellow packet operators so that we 
can all help each other maintain, 
expand and speed up the powerful, 
impressive Amateur packet radio 
network. 


Send your comments to Tucson 
Amateur Packet Radio (TAPR), 
8987-309 E Tanque Verde Rd 
#337, Tucson, AZ 85749-9399; tel 
817-383-0000; 

Internet psr@tapr.org. 
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Proposal: A High Speed 
Multicast-capable Packet 
System for the 219 Mhz 
Band 


Jeff King WB8BWKA 

Internet: jking@merit.edu 

Packet: wh8wka@detroit.ampr.org 
Date: 9/4/94 


On August 19-21, 1994, I had 
the pleasure of attending the 
ARRL Digital Networking 
conference in St. Paul Minnesota. 
One of the committee meetings 
that I attended was a joint session 
of the ARRL Futures and 219Mhz 
committees. One of the goals of the 
219Mhz committee was to occupy 
the band once we obtain it. Phil 
Karn, KA9Q, proposed that the 
band, in part, be used for 
multicasting. What | propose here 
(and there also) is asystem that will 
be multicast capable (when (he 
protocol issues are ironed out) and 
be put to immediate use today, 


One of the problems with packet 
is that it is half duplex. Even at 
medium speeds, such as 9600 bps, 
you are lucky if you can utilize half 
the channel capacity with our 
current system. While you 
certainly could operate full duplex, 
this would preclude others use of 
the channel due to the full 
occupancy of both of the channels 
(RX and TX), 


Statistics on people’s usage of 
the internet show that the majority 
of the data exchanges are 
asymmetrical, That is, you receive 
far more then you send. This factor 
can be to our advantage, both from 
a technical as well as economical 
perspective in Amateur radio 
tcp/ip. 

A system like this is already in 
use on the Amateur PacSats. There 
are multiple low speed inputs with 
one high speed output. I propose a 
similar system for terrestrial use. 
With the high speed output on the 
219mhz band (and users receiving 
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there) you have greater control 
over placement of transmitters, 
which will be a requirement of the 
219Mhz band that is a shared band, 


The system would consist of one 
high speed output (128 Kbaud to 256 
kbaud) on 219 or 222/223 MHz and 
multiple medium speed (9600 baud) 
inputs on different bands, lets say 
440 for now (but it just as easily 
could be 2m 9600 baud). The high 
speed channel could be based on a 
GRAPES MSK modem, transmitter 
only. This would feed an 
omni-directional antenna. Power 
output would vary depending on 
coverage required. The user inputs 
could be based on TEKK 440 data 
radios (or DR-1200), Antennas 
would be shaped coverage (beams or 
otherwise) directed towards the user 
area one wished to cover, Initially the 
user inputs (440 9600bps) could be 
simplex based, depending on 
height/coverage, one might want to 
make them mini repeaters so one 
could get DCD and eliminate hidden 
terminals, This has another 
advantage. Lets say you are running 
4 9600 inputs at about 1 watt ( User 
areas: North, East, South, West). 
You'll need to space them at least 
| Mhz. apart if you are at the same site 
and running | watt or so. If you run 
them as repeaters/DDR' s (not hard at 
all at the 1 watt level), you can have 
them on adjacent channels. (i-e. 
441.075/446.075 441.1/446.1 
441.125/446.125 441.150/446,150). 


On the digital hardware end, life 
is simple also, The Ottawa ‘PI’ board 
would be a perfect fit for this, both 
from the client (user) and server end, 
The PI board is a $125 (U.S) board 
that has two ports on it similar to a 
DRSI with the exception that one 
port is DMA based, Meaning, you 
can run S6Kbaud on XT based 
machines with ease. Obviously, 
things work much faster on better 
class machines. The TEKK radio is 
inthe 100-110 dollar range. A TAPR 
9600 baud modem would set you 
back around $80. The server would 
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be a 386+ class machine with 
multiple ports. 


The real beauty of this plan is its 
scalability, system economics, and 
pay as you go feature. Remember, I 
mentioned it could be done today 
with existing hardware. A user 
(client) would initially purchase the 
9600 baud equipment. With this, he 
could communicate with users on his 
LAN as well as do standard half 
duplex routing through the 
server/router, This is what we have 
today on the 2m 9600 baud as well 
as 440 9600 baud channels in the 
Detroit area, However, once the user 
wanted to upgrade, he would just 
need to purchase a 219 Mhz 
receive-only modem/receiver, 
which could consist of simply a 
wide-band police scanner or a 
low-cost Hamtronics receive 
transverter. Due to multipath 
concerns, all user stations would 
need to use beam antennas for the 
high speed channel (pointed at the 
server), 


System economics is where this 
really shines also. Thatis, the system 
cost (add all the user costs+the server 
costs) is less then with standard high 
speed systems, If the server system 
invests in a higher power/better 
coverage high speed channel (and 
remember, there are no hidden 
terminals due to the fact there is only 
one transmitter on the server 
frequency) then the total system cost 
is reduced. This is due to the fact the 
users do not need to invest heavily in 
high antennas/towers fo receive the 
site in addition they only need be 
concerned about receiving the site at 
high speed, their transmitting is only 
done locally with modest 
(inexpensive) equipment. Initially, 
the user station would do 
symmetrical routing (as would the 
server), that is, out the same port he 
receives on. (User: route add 
server.ampr.org 440, Server: route 
add user.ampr.org 440) When he 
added his high speed 219 receive 
port, his routing then would be the 
same (route add server.ampr.org 
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440) but the server would return to 
him on the high speed 219 channel 
(route add user.ampr.org 219). 


Now, how about some of the 
potential problems? When grabbing 
stuff from the internet at high speed, 
there will be plenty of *holes’ on the 
medium speed channels to get a 
*packet in edgewise’ due to the fact 
that most ACKs are quite short. 
Since the high speed channel is being 
controlled by a router (it’s not a 
DDR), it will be easy to interleave 
packets even if it is keyed 
continuously. User stations will be 
able to communicate amongst 
themselves as they do now (on 
simplex). Since the 440 (2m) radios 
will be RX and TX, DCD will be 
maintained reducing collisions. The 
only potential problem we will have 
is if auser wishes to send a file to the 
internet. Then we would run into a 
problem that the 9600bps channel 
would be continuously occupied 
(with ACKs coming back at 
56Kbaud on 219). I believe this 
problem could be solved in software. 
Obtaining a high speed internet feed 
could be a problem, but here in the 
Detroit area we have two 
well-connected sites (WSU and 
MERIT) that could feed the 
multicast server (which is a high site 
by definition). 


OK, so how can we do this now? 
We can start on a S56kbaud TX 
channel in the 222/223 range... we 
may have to be a bit creative, i.e., 
horizontal polarization, overlay on 
top of distant repeater outputs, but 
technically it is very do-able. When 
(if) we get the 219Mhz band, we 
move the server down there and up 
the speed to 128Kbaud. The user 
would simply need to move his 
receiver as al] his hardware will still 
be capable of the higher speed (on 
AT class and above). And of course, 
our medium speed user channels are 
already going into place. 


Now I've just talked about a 
system that could be implemented 
today. Like high speed access to 
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Mosaic (faster than any phone 
line), WWW, FTP’s, Archies, you 
name it. These are all client/server 
applications. How about 
multicasting? 


How would you like to receive the 
entire USENET feed? How about all 
the AX.25 bulletins? Would you like 
to watch NASA select (the space 
shuttle liftoffs) video from you PC 
screen? Listen to internet talk radio? 
Have multi-media roundtable’s? All 
this is possible (and much of it 
already happening) with 
multicasting. With multicasting you 
don’t acknowledge’ every 
transmission and multiple users can 
receive the same data. This is going 
to be much of the future both for the 
internet side as well as the AX.25 
side for bulletin/information 
distribution, And one other 
possibility of Amateur multicasting, 
that was mentioned at the DCC is the 
fact thata SWL (DWL?) will be able 
to receive most of this information. 
This would also attract users (SWLs, 
DWLs) to the hobby. 


So folks, what do you think? It 
won't take a rocket scientist to do this 
and it can be done today with off the 
shelf equipment. It will have to be a 
group effort though, as many things 
would have to fall into place, but it 
can happen if you wish it to. Speak 
up if you think it’s a good idea, bad 
idea, questions, or haye some 
thoughts.. I personally want to get 
high speed internet access and this 
seems to be the most economical 
way I have run across yet, 
Remember, if you do nothing, 
nothing will happen. Let’s here from 
you. Comments, questions to 
semcon @detroit.ampr.org 
Reference: 

Karn, Phil (KA9Q). (1987). A 
High Performance, Collision-Free 
Packet Radio Network. Proceedings 
of the ARRL 6th Computer 
Networking Conference, Redondo 
Beach, Calf, August 29, 1987, pp. 
90-94, 
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Help TAPR Create a Data 
Base of Regional Packet 
Organizations 


TAPR is generating an accurate 
list of regional and local packet 
groups. 


Many of the lists we have seen 
published in the last few years have 
been woefully out of date, TAPR 
feels that an accurate listing for 
regional/local packet groups is 
necessary to help exchange 
information and allow TAPR to 
tell people how to contact their 
regional/local groups. 


We will distribute this 
information tn various future 
TAPR publications. So, getting 
this club information correct will 
help your group as well as TAPR. 
In addition, we will be adding each 
of the groups to the PSR mailing. 


TAPR believes that local and 
regional groups are essential for 
educating and supporting local 
operators. As a_ national 
organization, TAPR can provide 
the necessary glue and information 
sharing needed to tie all our groups 
together. 


The Board has been busy 
transforming TAPR from strictly a 
hardware / software development 
group, into a more well-rounded 
membership society which 
continues to work on technology. 


In the future, it is hoped that 
together, TAPR and the regional 
packet groups can provide the kind 
of leadership that digital 
communications enthusiasts are 
eagerly looking for. 


You can provide information for 
the data base by mail, FAX, phone, 
or Internet: tapr@tapr.org. We 
look forward to your feedback. 


P.S. If you have any suggestions 
on how TAPR can work with your 
group or others, please feel free to 
give us a call or send e-mail. 
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TAPR Organization News 


Nominations Sought 
for TAPR Board of 
Directors 


Tucson Amateur Packet Radio 
is incorporated in the State of 
Arizona as a non-profit scientific 
and educational institution. It is 
recognized by the IRS as a501(c)3 
tax-exempt organization for these 
same purposes. TAPR is governed 
by a9-member Board of Directors. 
Each member of the Board serves 
a three year term, Every year, 
three positions are up for election. 


Board members are expected to 
attend the annual Board meeting 
held in conjunction with the annual 
meeting. They participate in the 
decision-making process and 
provide guidance to the officers. 
They receive no pay and must 
defray their own expenses to attend 
meetings. Board members should 
be prepared to be active in the 
continuing Board deliberations, 
which are conducted via the 
Internet. Active participation in 
TAPR activities by Board 
members is important to the 
furtherance of the objectives of 
TAPR. The officers of TAPR are 
elected by the members of the 
Board at the annual Board of 
Directors meeting. 


The current members of the 
Board of Directors and the 
expiration dates of their terms are: 


"Ron Bates, AG7H 1995 

“Jack Davis, WA4EJR 1995 

‘Jim Neely, WASLHS 1995 Treasurer 
Bob Hansen, N2GDE 1996 

Gary Hauge, N4CHV = 1996 Secretary 
Keith Justice, KF7TP 1996 Vice President 
Greg Jones, WDSIVD 1997 President 
John Koster, W9DDD 1997 

Mel Whitten, KOPFX 1997 


Nominations are now open for 
seats expiring in March 1995 
(marked with an asterisk). 


To place a person in nomination, 
please remember that he or she 
must be a member of TAPR. 
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Confirm that the individual is 
willing to have their name placed 
in nomination. Send that person’s 
name (or your own if you wish to 
nominate yourself) along with 
your call and their call, telephone 
numbers, mailing address, and 
Internet address. The person 
nominated should submit a short 
biographical sketch to be 
published along with the ballot. 


Nominations. and biographical 
sketches should be submitted to the 
TAPR office no later than 


December 10th, 1994. 
Ballots will be mailed the end of 
December directly to the 


membership and be due on or 
before February 24th, 1994, 
Results will be announced on 
March Ist, 1994, 


Responsibilities of a board 
member include: 
1) Attendance at the annual 
meeting and board meeting each 
year. 
2) Regular participation with the 
continuous session of the board 
(currently held over the Internet). 
Typically this requires a minimum 
of 2 hours a week, although 
sometimes much more is required 
during active board discussions. 
3) Participation with TAPR 
projects as volunteered. Board 
members, while not required, are 
involved with various project 
management, ongoing 
organization and/or supervision 
and liaison positions. Active 
board participation with various 
projects make many of the most 
important projects and tasks 
possible. Board members are 
expected to take an active part in 
TAPR in some form. 


All nominated members will be 
placed on the ballot and the highest 
vote receivers will be placed in the 
open board positions. If elected, 
the board meeting is Friday March 
3rd, 8am, in St Louis, Mo. A 
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board retreat is scheduled 
informally for March 2nd, in the 
afternoon to evening as board 
members arrive to the hotel. All 
directors shall serve for a term of 
three years. 


Office Closed for 
Christmas 


The TAPR office will be closed 
from December 15th through Jan 
9th. This means that Dorothy will 
not be answering the phone during 
office hours. The TAPR telephone 
system will contiue to operate, as 
well as the fax, and the mail will 
continue to arrive. 


Changes in the TAPR 
Telephone System 


We have been listening to the 
phone system survey (available on 
the system) and messages left 
concerning how we can improve 
the voice system. A majority of the 
calls indicated that they liked the 
system, but thought we should 
work on simplifying the overall 
range of choices. Based on these 
suggestions, we have made some 
changes. All the various 
informational choices that were 
available under each category have 
been consolidated under the 
Information selection. The other 
selections now take you right to 
Dorothy during office hours or into 
the voice mail system. The 
system continues to receive 
numerous calls and these changes 
should reduce any possible 
confusion and speed up your 
selection choice. The Fax back 
capability has been getting a lot of 
use. Daye Wolf, WO5H, 
continues to help with recording 
the messages heard on the system. 
We would like to thank Dave for 
his time in driving up from 
Burleson, Texas to help with this 
task. 
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TAPR Organization News 


RUDAK-U 


The RUDAK-U project fund 
raising has been going well. As of 
this writing we have raised $1,500. 
We still need another $4,000 in 
order to complete this fund rasier. 
We would like to thank all the 
contributors thus far for their help. 
If you belong to a local or regional 
packet group, suggest that the 
group provide money for this 
unique digital project. A few $250 
donations from digital groups 
would make our goal of reaching 
$6000 easy. RUDAK-U has some 
tremendous future in personal and 
regional high-speed digital 
communications, but requires 
further funding. Talk to your local 
or regional packet group. 


Donations above $25 will 
receive acertificate indicating their 
funding of RUDAK-U, while 
donations of $250 or more will 
receive a plaque to let all know of 
their efforts with this project. All 
donations are needed, both large 
and small. You can call the office 
at (817) 383-0000 or Fax (817) 
566-2544 to make your donation 
by MC/Visa. 


Dayton 95 — The 
Packet Connection 


TAPR hopes to host Dayton’s 
biggest and best packet event at 
next spring’s HamVention. 
Together with the Miami Valley 
FM Association, a Dayton club 
with a strong packet radio interest, 
we plan to have a Friday evening 
dinner program with speakers, 
separate break-out sessions, and a 
prize raffle. Saturday evening will 
continue with an informal dinner 
and more forum sessions, We 
invite all packet groups to join us 
for these events. Stay tuned for 
more details. Dayton will continue 
to be an important activity in which 
TAPR participates. 
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DSP-93 Update 


The DSP-93 initial kit offering 
is sold out and we are working on 
orders for a second run to be done 
in March, Orders must be placed 
before December 31st, 1994, price 
is $430. 


There has been so much 
happening with the beta-testing it 
is hard to cover it all. As of this 
writing the following modes have 
been tested and working on the 
DSP-93 beta units: 9600baud FSK 
full-duplex satellite, 9600 baud 
FSK terrestrial, 1200 baud PSK, 
300/1200 baud AFSK, RTTY, 
AMTOR, PCTOR, Audio Filters, 
a large assortment of test 
programs, APT, a Windows and 
Macintosh interface program, and 
the list continues to grow, 


For international buyers who 
have something other than 110v 
60Hz power, the price of the 
DSP-93 kit is being reduced to 
$420 and the 9 volt AC wall 
transformer will not be included. 
Please indicate this when ordering. 
9 volt AC power will need to be 
provided by the builder. 


The technical support for the 
first production units and 
successive kit releases will be 
conducted on Internet. If you are 
getting a kit, you need to either find 
a feed to and from the mail group 
or find a group to help each other. 
Plus, there will most likely be alot 
of support on the various 
store-and-forward satellites. The 
DSP-93 kit is such, that no one 
individual within TAPR or 
AMSAT will be able to support the 
build phase of any kit group, It will 
be up to previous builders to help 
those that follow, 


TAPR will be forming two new 
mail groups on DSP this fall, One 
is named DSP, which will focus on 
DSP software development and 
DSP-93 to focus on the DSP-93 kit. 
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Look for information on these later 
this year. We are still aiming at 
having kits shipped around the 
middle of November. To get 
information on various TAPR lists, 
send mail to ‘listserv @tapr.org’ 
and in the message body include 
‘help’ (no quotes). 


AN-93 Kit Update 


The AN-93 kit had a setback in 
August. The new Printed Circuit 
Board should be finished as of this 
printing and available for sale. 
The AN-93 kit provides any PC 
user with the capability for 
operating RTTY, AMTOR, and 
PCTOR with this simple 
modem-only design. AN-93 is the 
equivalent of a BayCom, BayPac, 
or PMP setup, but for HF digital 
operations. This very simple kit is 
for those that have wanted to play 
on HF, but didn’t want to pay the 
money for an expensive 
multi-mode controller. TAPR will 
be doing a limited run of 100 
AN-93 kits. This is not a beta-test, 
but a market test to see what the 
level of interest is in this kit design. 
The AN-93 comes with a tuning 
indicator to allow visual tuning and 
the unit also provides audio output 
for oscilloscope display. 


Introduction of the 
TAPR HF Special 
interest Group. 


TAPR is proud to announce the 
formation of a Special Interest 
Group focusing on HF Digital 
Issues. Johan Forrer, KC7WW, 
will be the Chairperson of this 
group during its initial formation 
period. See the HF-SIG 
introduction in this issue to see the 
objectives and goals of this group. 
The TAPR Board looks forward to 
the future activities of this group. 
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TAPR.ORG Update 
(Yet Again) 


Things are on the change again 
with the TAPR.ORG server. We 
are relocating the Internet server to 
a more permanent location, which 
has full Internet access. This 
change has been brought about by 
several factors: |) the need for 
better access with more reliable 
service and a long-term location, 2) 
our current system sysop, Lou 
Nigro, KW7H, is having to cut his 
commitment to maintaining the 
server, 3) the need to cut 
operational costs for maintaining 
the system and 4) to provide one 
location for file-requests, ftp, and 
mail groups. 


The purpose of the initial 
TAPR.ORG server, which was 
initiated at the TAPR Board of 
Directors meeting in 1993, was to 
prove that Internet access would be 
a better method of BoD activity 
than CompuServe, and would 
provide better information access 
to the membership. Both goals 
have been successfully met, as 
indicated by the BoD and 
membership activity over the past 
two years. As the TAPR.ORG 
service grew, the system we were 
using had been strained to take the 
additional load. This appeared in 
full force when we crashed the mail 
server of our provider and moved 
the three mail groups in one night 
to the TCET.UNT.EDU Internet 
site. 


The new site is currently located 
at DATAPOINT.COM and will 
stay there until the node which will 
eventually house TAPR.ORG is 
installed. Lee Ziegenhals, 
NSLYT, has been of tremendous 
help in this relocation. Lee is 
providing the current access and is 
helping with the setup and 
maintenance of the new system. 
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The new server is using 
ListProcessor 6.0. This system 
supports both mail lists and an 
e-mail file request system. The 
server can be reached by using our 
current “listserv @tapr.org” or 
“file-request @tapr.org”. 


The three TAPR mail lists 
currently supported on 
TCET.UNT.EDU will have been 
moved to the TAPR.ORG by the 
time of this printing. So, to join the 
SIG mailing lists, you will need to 
use the new address of 
“listserv @tapr.org” instead of the 
tcet.unt.edu address. 


Here is a brief set of basic 
requests: 


help 
Get the basic help file. 


index -all 
Get a list of files in all archives. 


get <archive> <file> 

Get the requested file from the 
specified archive. Example: 
get tapr taprinfo.txt 
lists 

Geta list of all local mailing lists 
that are available. 


subscribe <list> <your 
name> 


The only way to subscribe to a 
list. Example: 
subscribe tapr-bb Joe Ham 
unsubscribe <list> 
signoff <list> 

Two ways of removing yourself 
from the specified list. Example: 
signoff netsig 
information <list> 

Get information file about the 
specified mail list. 


which 
Geta listing of local mailing lists 
to which you have subscribed. 


User Oriented Requests 
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You can ’set list mail ack’ in 
which case messages to the list will 
be echoed back to you, and ’set list 
mail noack’ (the opposite). The 
default is set to ’mail ack’. 
Example: 
set netsig mail noack 

A’set list mail postpone’ request 
will not send any messages to the 
subscriber until he resets it to one 
of the other options (used to 
suppress sending e-mail 
temporarily). 

Example: 
set netsig mail postpone 

A ‘set list mail digest’ will only 
send messages at the end of each 
day as a digest. 

Example: 
set netsig mail digest 

A ’set lis? with no arguments 
returns the current values for all 
options. 

Example: 
set netsig 

You may hide your identity by 
issuing a “set list conceal yes’ 
request. 

Example: 
set netsig cdnceal yes 


ARRL 14th Digital 
Communications 
Conference 1995 


TAPR is proud to announce that 
TAPR and TPRS (Texas Packet 
Radio Society) will be co-hosting 
the 1995 ARRL_ Digital 
Communications Conference 
during September, 1995, in 
Arlington, Texas (near Dallas/Ft. 
Worth airport). (Most probably 
the same location used by 
AMSAT-NA for their 1993 
national convention.) This facility 
allows easy access to the DFW 
airport and provides lodging at a 
very reasonable rate. A final date 
and full information should be 
available the first of 1995. 
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A Network Building 
Opportunity 


Carl Bergstedt KOVXW 


Last March, at the annual TAPR 
meeting in Tucson, I presented a 
project idea to the TAPR board. 
The plan was to involve TAPR in 
some way with the introduction of 
the RF hardware developed by the 
Karlsruhe Packet Radio Group, 
that has been so sucessful in the 
German packet network and in 
surrounding countries. 
Wolf-Henning Rech, DF9IC, and 
other members of the project team 
have developed 23 cm packet radio 
hardware that has been used in over 
300 nodes in the German PR 
network, 


Their latest development is a 23 
cm full-duplex system that is 
capable of 19.2 Kbps using 
G3RUH compatible FSK modems. 
It is now available in Germany as 
separate transmitter, receiver, and 
power amplifier kits designed 
specifically for data service. 


With our current lack of 
spectrum for high speed (greater 
than 9600) linking in urban and 
| 1.2 GHz Digital Radio] % 


es Vv 


| (Enter quantities desired) 


‘J would be interested in___: 
‘complete rf transmitter, receiver, | 
‘and 2 watt PA kits and assembled | 
‘and tuned duplexer(s) 


I would be interested in ____! 
‘complete rf transmitter, receiver, | 
‘and I5 watt PA kits and: 
‘assembled and tuned duplexer(s) | 


Callsign, for further info only: | 


: Mail to: : 
Tucson Amateur Packet Radio| 
' 8987-309 East Tanque Verde #337 | 


Tucson AZ 85749-9399. 


metropolitan areas, 23 cm seemed 
to be a good choice to use for 
linking. Small, high gain antennas 
or dishes allow low power node RF 
equipment. Relatively inexpensive 
RF transistors and power amplifier 
modules make 23 cm RF hardware 
feasible. 


Depending on antennas and 
elevation, 15 watts can allow node 
separations in excess of 60 miles. 
The 2 watt PA could be used in 
metro areas where node spacings 
are 30 miles or less. 


Abbreviated specifications for 
the transmitter are in Table 1. 


The receiver uses a similar 
crystal multiplier and is a triple 
conversion unit with intermediate 
frequencies of 74.7 MHz, 10.7 
MHz, and 455 KHz. It is operated 
with a frequncy offset of 49 or 59 
MHz to work with the interdigital 
filter / duplexer designed by 
DF9IC,. The abbreviated 
specifications for the receiver are 
in Table 2. 


The duplexer designed for the 
full-duplex system is made of a 
rectangular aluminum section, 
approximately 60 x 33 mm and is 
430mm long. There are 11 solid 
aluminum rod resonators of 
varying diameters and lengths that 
are fastened inside of the 


rectangular aluminum housing. 
Eight screw adjustments are used 
to tune the resonators, and three 
resonator rods are attached to 
connectors for the receiver, 
transmilter, and antenna ports. The 
duplexer has a passband insertion 
loss of 1.2 dB. Over 100 dB 
isolation is attanable at 59 MHz 
offset, with mimimum isolation of 
80 dB at 35 MHz offset, with a 
maximum insertion loss of 1.6 dB. 


TAPR would like to judge the 
extent of interest in this hardware, 
prior to making arrangements with 
the supplier of these kits to import 
them for sale in the U.S. Exclusive 
of any import duties, the 
full-duplex system would cost 
approximately $500 with a 2 watt 
PA or $550 with a 15 watt PA. 
These prices would include an 
interdigital filter / duplexer 
designed by DF9IC, tuned up on 
specified transmitter and receiver 
frequencies. 


Please indicate your interest by 
completing the coupon below (or 
similar) and mailing to TAPR. 


No commitment on your part is 
implied, but TAPR would prefer 
that you reply only if you have a 
genuine interest. TAPR will 
proceed if there is significant 
interest. 


Table 1. Transmitter Specifications 


Frequency coverage 1150 to 1350 MHz 
Output power +12dBm min. 
Crystal frequency Ft/128 w/30pf load capacitance 3.5 ppm from 0-60° C 
Stabilization PTC thermistor attached to crystal holder 
yields < +/- 5KHz from -10° to +50° C 

Deviation 2 Vp-p yields 5KHz swing 
Frequency response Flat from < 1 Hz to > 20KHz 
Usable FSK Data rate 4800 to 19,200 min. 
Input impedance 47K in parallel with 1 nf. 
Supply voltage +12 to 15VDC 
Supply current 170 ma. typical 

Table 2. Receiver Specifications 
Frequency range 1100 to 1300 MHz 
Supply current 250 ma, f 
Image rejection > 40dB 
IF Bandwidth 30 KHz 
Noise level 3 dB 
Sensitivity (BER=1e-6)  -113dBm 
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The Tucson Amateur Packet Radio Corporation is a non-profit, scientific 
research and development corporation. TAPR is chartered in the State of 
Arizona for the purpose of designing and developing new systems for packet 
radio communication in the Amateur Radio Service, and for freely dissemi- 
nating information required during, and obtained from, such research. 

The officers of the Tucson Amateur Packet Radio Corp, are: 


Greg Jones, WDSIVD President 
Keith Justice, KF7TP Vice President 
Gary Hauge, NSCHV Secretary 
Jim Neely, WASLHS Treasurer 


The Packet Status Register is the official publication of the Tucson 
Amateur Packet Radio Corporation. Unless otherwise indicated, explicit 
permission is granted to reproduce any material appearing herein, provided 
credit is given to both the author and TAPR. 


TAPR Membership and 


PSR Subscription Mailing Address: 
Tucson Amateur Packet Radio Corp, 
8987-309 E. Tanque Verde Rd. #337 

Tucson, AZ 85749-9399 
Phone: 817-383-0000 
FAX: 817-566-2544 
Office Hours: 
Tuesday - Friday 
9:00-11:00am, 3:00-5:00pm C.S.T. 
14:00-16:00, 20:00-22:00 UTC 


PSR Editorial Address: 


TAPR Board of Directors 


Board Member Term Internet 

Ron Bates, AG7H 1995 ag7h @tapr.org 
Jack Davis, WA4EJR 1995 = wadejr@tapr.org 
Bob Hansen, N2GDE 1996 =n2gde @tapr.org 
Gary Hauge, N4CHY * 1996 = n4chv @tapr.org 
Greg Jones, WDSIVD * 1997 = wdSivd @tapr.org 
Keith Justice, KF7TP * 1996 ~— kf 7tp @tapr.org 
John Koster, W9DDD 1997 w9ddd @tapr.org 
Jim Neely, WASLHS * 1995 waSlhs@tapr.org 
Mel Whitten, KOPFX 1997 —kOpfx @tapr.org 


Date is expiration of term on Board of Directors. 
Asterisk indicates member of Executive Committee. 


The Board encourages input from all interested members. 
If you have an issue you want addressed, or an idea fora project 
you would like TAPR to sponsor, contact any Board member, 
or drop a note to the TAPR office. 

TAPR is now accessable through the Internet. You may 
send e-mail messages (no long files, please) to the TAPR 
office at 

tapr@tapr.org 


and to any of the directors at 
callsign@tapr.org 


Bob Hansen, N2GDE 
PSR Editor substituting their call for “callsign.” Also, submittals for 
P.O. Box 1902 Packet Status Register may be sent to 
Elmira, N.Y. 14902-1902 psr@tapr.org 
CompuServe: 71121,1007 
Internet: psr@tapr.org 
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Check your address label for membership expiration date. Your renewal is important! 


